Web applications are now an essential part of our lives in the digital era. However, they also bring the risk of cyber attacks, which can lead to data breaches, theft of sensitive information, and significant financial losses. Thus, it is crucial to take necessary security precautions to protect your web application.

In this blog post, we will discuss common web application vulnerabilities and how to secure our web applications to prevent them. The ColoredCow team recently conducted a security audit and implemented measures to mitigate these vulnerabilities for one of our clients. This blog shares the expertise and lessons learned from that experience.

To secure your web application, implement security measures at both the web server and application levels. This multi-layered approach can include SSL/TLS, web application firewalls, input validation, output encoding, and other techniques. These security fixes help protect your web application from potential cyber-attacks, safeguarding sensitive data.

In this blog, we will be taking a look at:

1. Web server security best practices.
2. Secure software development practices.

Web Server Security best practices

The web server configuration is crucial for the security of a web application. Here are some security headers that you can use to secure your web application:

1. X-Powered-By:

The “X-Powered-By” header explains the technologies used by the web server, ie which web server is being used at the server end. This information exposes the server to attackers. Using this information, attackers can find vulnerabilities easier known to the technology or framework.

Recommendation:

To protect against this, it is recommended to remove all “X-Powered-By” headers from the production server.

2. Option method:

The HTTP OPTIONS method is a type of HTTP call that explains what are the options available for a target resource such as an API endpoint. ie. We can send an HTTP request using the OPTIONS method to see what other types of request methods can be used (ie GET, POST, PUT, DELETE, etc.) when requesting information from a resource (ex API endpoint).

Recommendation:

Disable the OPTIONS method from production unless you explicitly need it.

3. Strict-Transport-Security:

The HTTP Strict-Transport-Security (HSTS) response header lets a website tell browsers that it should only be accessed using HTTPS, instead of using HTTP.

Recommendation:

Use theHSTS header to prevent “man-in-the-middle” attacks and ensure that users’ sensitive information remains secure.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age – Defines the time in seconds for which the web server should only deliver through HTTPS.
• includeSubDomains – It indicates that the HSTS header will be implemented for the includeSubSomains as well.
• preload – This flag indicates the site owner’s consent to have their domain preloaded. The site owner still needs to then go and submit the domain to the list.
  
  

4. Content-Security-Policy:

This header specifies the origin of content which is allowed to be loaded on the website, preventing various types of attacks such as Cross-Site Scripting (XSS), data injection attacks, etc.

Recommendation:

You can deliver a Content Security Policy to your website in the following ways.

• Content-Security-Policy Header – Send a Content-Security-Policy HTTP response header from your web server. Using a header is the preferred way and supports the full CSP feature set. Send it in all HTTP responses, not just the index page.
  Content-Security-Policy: ...
• Content-Security-Policy Meta Tag – This way, you can secure your application where headers are not in your control. For eg, deploying the static application in a CDN. Use this header by specifying an HTTP-equiv meta tag in the HTML.
  <meta http-equiv="Content-Security-Policy" content="...">

5. X-Frame-Options:

This header controls whether the website can be loaded in <frame>, <iframe>, <embed> to prevent clickjacking attacks by ensuring that their content is not embedded into other sites.

Recommendation:

1. Use Content Security Policy (CSP) frame-ancestors directive if possible. Most of the 
2. Do not allow displaying of the page in a frame. Use the following HTTP header.
   X-Frame-Options: DENY

6. Access-Control-Allow-Origin

For Cross-origin resource sharing (CORS). This header defines whether the requesting domains have access to the website’s resources or not. It’s recommended to limit this to trusted domains. When a site tries to fetch content from another site, the Access-Control-Allow-Origin header specifies where the content of a page is accessible.

Recommendation:

It is recommended to avoid wildcard “*” and whitelist the origin to allow the specific origin to access the resources.

• Wildcard origin – The value tells browsers to allow requesting code from any origin to access the resource.
  Access-Control-Allow-Origin: *
• Whitelisting Origin – The value tells the browser to allow requesting resources from a specific origin.
  Access-Control-Allow-Origin: <origin>

Below are a few other HTTP headers you can use to enhance your web application security.

1. X-XSS-Protection
2. X-Content-Type-Options

Secure software development practices:

1. Insufficient Input Validation and Sanitization

Input validation and sanitization are crucial for preventing attacks such as SQL injection, Cross-site scripting (XSS), and Command injection.

Recommendation:

1. Use prepared statements or parameterized queries to prevent SQL injection attacks. Prefer using frameworks over building from scratch, as most of the frameworks come up with such best practices implemented.
2. Use a whitelist approach for input validation, allowing only known good input and rejecting all other input.
3. Use output encoding to prevent cross-site scripting attacks.
4. Use the available input sanitization library/plugin (eg. DOMPurify for javascript-based frameworks) to properly sanitize your input before submitting/storing it to the database.

2. SQL Injection Vulnerability

SQL injection is a type of attack where an attacker inserts malicious SQL code into a query, allowing them to retrieve or modify sensitive data.

Recommendation:

Here are some ways to prevent SQL injection attacks:

1. Use prepared statements or parameterized queries.
2. Use input validation and sanitization.
3. Avoid dynamically generating SQL queries.

3. Cross-Site Scripting (XSS) Vulnerability

XSS is a type of attack where an attacker injects malicious scripts into a website, allowing them to steal sensitive information, such as user credentials.

Recommendation:

To prevent XSS attacks, you can use the following techniques:

1. Input validation and sanitization to prevent the injection of malicious scripts.
2. Output encoding to prevent the execution of malicious scripts.
3. Using Content Security Policy headers to limit the sources of executable scripts on the page.

4. API rate limit

It is a security measure that limits the number of requests that can be made to an API in a given time. This helps prevent attacks such as Denial of Service (DoS) and Distributed Denial of Service (DDoS).

Recommendation:

To implement the API rate limit, you can use tools like Nginx or Apache to set the limit on the number of requests per minute or hour.

Conclusion

Web application security is crucial for protecting sensitive information from malicious attacks. The vulnerabilities discussed in this blog post are just a few examples of the many types of security threats that web applications can face. To ensure the security of your web application, it’s important to regularly review and update your security measures, implement security best practices, and stay up-to-date with the latest security trends and threats.

By taking these steps, you can reduce the risk of attacks and keep your web application and its users safe.