A checklist to protect web applications against the most common attacks

When a new web application is deployed, it’s usually submitted to security checks. But there’s also a rush to go to market, so it’s not uncommon to deploy the first release of an application with low security conditions.

Every three to four years, OWASP publishes a list of the top 10 web-application security risks. This list reflects the most common errors in the implementation of web services.

During my career, I’ve worked on the development of several web applications with high-security implications. In this time, I’ve committed, found, and fixed all of these kinds of errors. I’ve also performed some ethical hackings, so I have an idea of where developers usually fail.

In this article, I’ll highlight different security aspects to consider before deploying a web application, independent of the underlying technology.

Disclaimer: This is security checklist is based on the OWASP Top 10 and my own experience. Your web application might not require some of the points in this list or might require some security considerations not listed below.

✅ Design

A good API design is key for avoiding security issues. Following design best practices and having good API documentation can help in the identification of red flags in a restful API.

There are guides and specific tools, like Swagger Editor and the OpenAPI Specification, that are very useful for these purposes.

✅ Authentication and Authorization

Most of the time, your application will have a private area, so you should perform an authentication and authorization control before executing any request.

These controls should prevent the execution of any action if the requester isn’t a valid user with an active session and the required permissions.

Good API documentation should include authentication details.

✅ Access Control — CORS

Access control should be restricted to the web application domain (or a whitelist). If CORS is enabled on the server, a preflight request will check if the origin of the request is allowed, throwing an error if it’s not.

It’s common to use a very permissive CORS configuration in the development stage and to accidentally deploy this configuration in a production environment.

You can test if CORS is enabled on your server with test-cors.org.

✅ SQL Injection

This attack consists of the execution of a form-injected query in the server database. In this way, a hacker could extract, modify, or delete data from our database or system.

The best way to protect our server from this kind of attack is by sanitizing all of the parameters that could end in a database query.

sqlmap is a great tool to identify SQL injection flaws.

✅ HTTP Security Headers

HTTP security headers are useful for protecting our application against common attacks. Libraries like Helmet allow us to add these headers seamlessly in Express apps.

There are a lot of HTTP security headers for different purposes that can help in the mitigation of the most common attacks:

XSS attacks

A cross-site scripting (XSS) attack consists of the execution of arbitrary JavaScript code injected by an attacker into a trusted website. XSS was the seventh most common web application vulnerability in the latest OWASP Top 10 (2017).

Using the Content-Security-Policy header and strict input sanitization can prevent and mitigate the risk of an XSS attack. If you need to support legacy browsers, you should also set the X-XSS-Protection header.

Clickjacking

Clickjacking consists of hijacking the interaction of the user in a website, such as their clicks or keystrokes, using an invisible frame in the top layer to trick the user into performing unintended operations.

We can increase the protection of our application by adding the HTTP headers Content-Security-Policy frame-ancestors, or X-Frame-Options to prevent our site from embedding or being embedded into an iframe.

CSRF attacks

Cross-site request forgery (CSRF) is an attack that forces a user’s browser to execute unwanted actions on a web application in which they’re currently logged into.

The main mitigation measures for CSRF attacks are the use of CSRF tokens and SameSite cookies. For Node.js applications, the csurf module creates a middleware for CSRF token creation and validation.

✅ Error Handling

As stated in Murphy’s law, if something can go wrong, it will go wrong, so your restful API should be ready to handle errors gracefully.

Avoid exposing information in the errors that could be useful for attackers (like technologies, versions, or very descriptive messages). Handle HTTP errors by just returning standard status codes and generic responses.

Good API documentation should include details for the different error responses, like unauthorized access or internal server errors.

✅ Logging, Monitoring, and Audit

It’s paramount to create and keep a log of the application server to be able to know what happened at any moment in time. The number and level of detail of collected logs are very application-specific.

Ensure a proper log rotation to avoid generating huge log files, and keep old log files according to the log-retention policy to comply with audit requirements.

If you have a SIEM, you can set these logs to create alerts and trigger alarms when an anomaly is detected in our application.

The latest OWASP Top 10 (2017) is the first one to include Insufficient Logging & Monitoring as a common web application security risk.

✅ Up-to-Date Systems and Dependencies

Every piece of software and each system should be regularly updated — at the very least to install security fixes.

Tools like Anchore or Snyk can help you spot known vulnerabilities so you can fix them quickly.

✅ HTTPS

Always establish a secure communication channel between the client and the server using HTTP over SSL/TLS.

You can enforce the use of HTTPS in a connection with the Strict-Transport-Security header (HSTS).

Final Thoughts

The security level must be adjusted to the sensitivity of the data you’re protecting. Security breaches can have serious consequences for a business, and sometimes security isn’t considered until there’s a problem — when it may be too late.

Although it’s impossible to be completely secure, taking these considerations into account can drastically reduce the risk of a security incident and its associated risks.

Thanks for reading!

Originally published here