TL;DR notes from articles I read today.
Top security best practices for Go
- You should validate user entries (using native Go packages or 3rd party packages) not only for functionality but also to avoid attackers sending intrusive data.
- Ensure each database user has limited permissions, that you are validating user inputs and that you are using parameterized queries to protect yourself from SQL injections.
- Make the best use of Go’s crypto package to encrypt sensitive information.
- Enforce HTTPS communication and implement in-transit encryption even for internal communication.
- Remember that error messages and error logs can expose sensitive information. Use the native library in Go for logs or third-party options like logrus, glog or logo.
Full post here, 6 mins read
Tips to power-up your Java security
- Protect against SQL injections by binding variables in prepared statements, using the prepareStatement() function to validate inputs.
- Returning mutable objects leaves you vulnerable to unexpected changes in your class state. Instead, use an unmodifiable/immutable collection or a copy of a mutable object to return.
- Avoid including XSS characters in log messages. Manually sanitize each parameter and configure your logger service to replace such characters.
- Always validate user input, especially when dealing with files whose location might be specified by user input.
- Replace predictable random values (java.util.Random) based on clock tickets or other predictable parameters with a secure random class and functions.
- Eliminate dynamic class loading.
Full post here, 4 mins read
Ways to secure your applications
- More than 70% of exploited applications are due to outdated dependencies. Ensure dependencies are up to date by using the latest packages and automating dependency management.
- Explicitly declare acceptable user payloads and use database-level constraints, like maximum column size, refusing null values, etc.
- Assert safe regular expressions.
- Limit requests by IP address or user agent.
- Store credentials outside your codebase, separating application configuration from code.
- Disable HTTP requests to your server unless very specific use cases demand it. Enable certificate checking for outgoing connections so that communication with third-party APIs or services are also secured by HTTPS.
Full post here, 9 mins read
Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().
Top comments (1)
Could you please explain why should we avoid dynamic class loading in Java? We kind of want to do that on our project very soon. Only users with access to the application folder would have access to that, so I don't know how could this be exploited.
Could you provide an example for that?