Improve the security of your Go application with the Go Security Checklist
Continue improving your security with Sqreen's monitoring and protection platform. It just takes a few minutes to get started.Try Sqreen now
Don’t implement your own crypto
Unless you’re a security expert — and even if you are — never implement your own crypto. Doing so is a common cause of security errors, as too few eyes have had a chance to review the code. Instead, use publicly reviewed, critiqued, and tested libraries such as https://golang.org/pkg/crypto/[the crypto package] in Go’s standard library. Then, educate yourself as much as possible on cryptography, by reading such books as GoCrypto by Kyle Isom, or take the Cryptography course on Pluralsight.
Keep your dependencies up to date
Most modern code relies on third-party dependencies. These need to be managed effectively, kept up to date, and scanned for vulnerabilities to ensure that your code is not exposed when using them. Use Go modules as your dependency manager and keep up to date with all of your dependencies.
Scan all third-party libraries regularly for known security issues using a security scanner such as gosec. You can also manage your dependencies and ensure that you’re notified if you’re using vulnerable ones with Sqreen.
Never store sensitive data in sessions
No sensitive data should ever be stored in a session. Ideally, only a minimum of data should ever be stored in a session. Otherwise, the information may result in unauthorized disclosure should the server be breached.
Don’t cache sensitive data
When you cache data to speed up your application, such as database requests, ensure that sensitive data isn’t cached.
Store passwords using strong hashing functions
Ensure that all passwords and other potentially sensitive data are hashed, using robust hashing functions such as Bcrypt.
Don’t use weak and vulnerable hashing functions, such as MD5 and SHA1.
Use secure middleware
Write simpler, more readable code
Authenticate your application
Ensure that only authenticated users are allowed into your application. Authentication defines whether a user is admitted into your system and is the first barrier to someone gaining access to your application.
Enforce access control with a reputable library
Log all the things
Never log sensitive data
Here’s the exception. While it’s essential to instrument applications and log events of all forms so that we have information to respond when things go wrong, we must ensure that no sensitive data is ever written to the logs.
Additionally, OWASP recommends that a cryptographic hash function be used to ensure no log tampering has taken place.
Be aware of vulnerabilities and security advisories
Even the best software contains bugs and security vulnerabilities, and the best developers make security-related mistakes. Make sure that you and your team stay up to date about all the latest vulnerabilities and security advisories, so that you are prepared when the time comes to patch your code.
Filter and validate all data
Regardless of where the data comes from, whether that’s a configuration file, server environment, user input — or anywhere else — do not trust it! Filter and validate it! Do this by using one of the available Go libraries.
Always perform output filtering
No matter where your application outputs information, avoid exposing your users to XSS (Cross-Site Scripting) and other forms of attacks by performing context-aware output filtering.
Stay up to date with the latest Go version
Use an application security testing tool like a SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), or IAST (Interactive Application Security Testing)
Testing your code pre-production is a smart way to reduce the number of vulnerabilities that make it to production and proactively uncover potential security flaws. There are several different types of tools that aim to help you do this. A SAST scans source code looking for vulnerable code or potentially vulnerable code. However, without any context as to how the application comes together, SAST tools often generate a large number of false positives and false negatives.
A DAST stresses your application from the outside, pre-production, by sending a wide range of malicious requests. DASTs have the advantage of simulating traffic and seeing how your application handles it, rather than just looking at the code, but often take extremely long to run and also generate a fair number of false positives, since they are application-blind.
An IAST leverages your production traffic data to more intelligently fuzz your application, giving you a higher signal-to-noise ratio and a faster runtime. However, for new code that hasn’t been in production yet, IASTs may not catch the vulnerabilities therein.
Use the OWASP Go secure coding practices guide
Use the OWASP secure coding practices for Go to avoid programming mistakes that could lead to vulnerabilities: https://owasp.org/www-project-go-secure-coding-practices-guide/
Integrate linters into your CI
Make requests over HTTPS wherever possible
To avoid Man-in-the-Middle attacks and to protect the privacy of your users, you need to make all requests over HTTPS—especially requests involving sensitive data, such as logins, passwords, and account changes.
Sandbox your Go program to reduce its attack surface by reducing its execution privileges
From file system access rights to process capabilities, disable everything by default and only specifically add what your program needs at runtime. Ideally, an overall defense-in-depth should be implemented so that every layer is hardened. Containers are a good starting point.
Do not store sensitive data in configuration files
Just like you shouldn’t store sensitive data in cache entries, you also should not store sensitive data in configuration files. This includes ssh keys, access credentials, and API tokens. Store them in environment variables instead.
Check your SSL / TLS configurations
Monitor your Domain Name expiration date
Just like TLS certificates, domain names can expire. Make sure you monitor your expiration dates automatically.
Backup regularly, test your backups, then backup again
Backup all your critical assets. Ensure that you attempt to restore your backups frequently so you can guarantee that they’re working as intended. S3 is a very cheap and effective way to backup your assets. Read more:
Send all available security headers
There are several security headers that you can use to make your web-based applications more secure for minimal effort.These include HSTS, X-XSS-Protection, X- Frame-Options, X-Content-Type-Options, and a Content Security Policy.Ensure that they’re being configured correctly and sent in your request responses.
Have a Content Security Policy
Whether you have a one page, static website, a large static website, or a sophisticated web-based application, implement a Content Security Policy (CSP). It helps to mitigate a range of common attack vectors, such as XSS.
Have a public security policy
This is a page on your corporate website describing how you secure your users and their data, and how you plan to respond to external bug reports. You should advise that you support responsible disclosure. Keep in mind that you will likely receive reports of varying impact, so having a process for prioritizing them is important.
Protect against Distributed Denial of Service (DDoS) attacks
DDoS attacks are meant to break your application and make it unavailable to your customers. Basic DDoS protections can easily be integrated with a CDN, but there are purpose-built DDoS protection tools available as well.
Implement CSRF protection
Protect your application from SQL Injection attacks
Do not concatenate strings that contain user-supplied information together and then use them in SQL queries. Avoid SQL injection attacks by using parameterized queries and prepared statements, using the DB.Query and DB.Prepare functions.
Protect your applications from SQL injection attacks in production with an Application Security Management platform like Sqreen. Additionally, you can use testing tools pre-production such as sqlmap, gauntlt, and safesql.
Protect your sensitive data in production
There’s no such thing as perfect security. Vulnerabilities in code, business logic, and more will always exist. Make sure you have a security solution in place that detects and blocks OWASP attacks in production in real-time, as well as business logic threats.
Monitoring and protection platform made to be incredibly powerful yet very easy to use.
Unmatched security insights: Access to more detailed security analytics than ever, including applevel incidents you can act on immediately.
Instant Protection: Out-of-the-box modules protect apps against a broad array of threats. Setup takes minutes, no config required.
Easily meet enterprise compliance needs: Get access to the best controls without hiring expensive security teams or consultants.
Want this handbook as a PDF?
Scan the QR-code, or go to: