Article summary
The security of an application is a highly important aspect of software development. But, sometimes it gets buried as more urgent (or just flashy and user-facing, if we’re being honest) tasks come up. It is tempting to bounce the responsibility of addressing security concerns off to a later date or a different team and stack it onto the project’s technical debt. Thankfully, it doesn’t need to be tedious to take a few substantial preventative security measures.
Security Concerns
Here are some security concerns and mitigations. Start with these to spare yourself future pain.
Http Parameter Pollution (HPP)
- If your application uses query parameters, attackers can add in unexpected extra parameters (for example – http://localhost:3000/firstUser=user111&secondUser=user222). Depending on the backend of your application, it might react very differently to unexpected parameters. It might take just the first, just the last, or accept them all in array form.
- Parameter pollution can intercept valuable information and screw with the performance of your application. It can even do things like bypass CAPTCHA tests. It’s worth taking seriously!
- A solution to this would be adding a web application firewall (WAF), deliberately specifying how to handle multiple parameters, or whitelisting certain parameters to be duplicated.
Clickjacking
- Clickjacking is an attack that involves layering applications on top of one another. An attacker might place an iFrame over your application’s buttons. This could cause users to click on content that appears innocent but is actually malicious. You certainly would not want to show your proud parents the cool new website you built, only for them to get suckered into the classic click-here-win-a-cruise-vacation trope.
- Prevent clickjacking on your application by adding a Content-Security-Policy header. This header can be set to different values depending on the strictness you require.
- In order to check the CSP header for a website, use a tool like this CSP evaluator to determine how secure it is against potential clickjacking attacks.
HTTP Strict Transport Security (HSTS)
- HSTS is a security policy that can help your application become resistant to man-in-the-middle attacks. After the initial use of the application, the browser will remember to only connect via HTTPS, regardless of how the user types in the URL.
Tools for Security Concerns
You can implement the following tools in your project. They can help you stay on top of security without requiring continuously high effort.
Coverity Scan
Coverity is a static analysis of your code, which means it won’t run through all your different code paths like an integration test might. The critical checks that it covers include audits for memory usage, insufficient performance, and possible misses on error handling. It will also catch flaws related to the security issues discussed above. That includes potential path manipulation, security best practices violations, insecure data handling, etc. Integrating a Coverity scan into a CI/CD pipeline can keep you ahead of security concerns you may not even be aware of.
Helmet
Helmet is a quick and easy way to solve a variety of security concerns with just a few minor adjustments. The package covers a default of 11 different header adjustments, covering all the security measures above and more. In a recent Typescript project, all it took was throwing `app.use(helmet());` into the server to get instant reassurance about potential vulnerabilities.
Develop a basic understanding of common vulnerabilities, stay on top of them with preventative strategies, and you can have confidence that you’re not exposing your application to common attacks.