Skip to main content

Insecure Configuration

This vulnerability category covers the following issues:

About Cookie Flags

HTTP cookies are small pieces of data that are sent from a website to a user's web browser and stored on the user's device. Cookies can be used for a variety of purposes, such as tracking user sessions, remembering user preferences, and serving targeted ads.

However, if cookies are not configured correctly, they can be vulnerable to attacks that can compromise the security of a website and the privacy of its users. One common vulnerability is the use of insecure cookie flags. Insecure cookie flags are settings that can be configured for a cookie to specify how the cookie should be transmitted and stored.

Some common insecure cookie flags include:

  • "Secure" flag: This flag indicates that the cookie should only be transmitted over HTTPS connections. If the cookie is transmitted over an insecure HTTP connection, it can be intercepted by an attacker and used to impersonate the user.
  • "HttpOnly" flag: This flag indicates that the cookie should not be accessible by client-side scripts, such as JavaScript. If the cookie is accessible to client-side scripts, it can be vulnerable to cross-site scripting (XSS) attacks.
  • "SameSite" flag: This flag indicates that the cookie should only be sent in requests that originate from the same site as the one that set the cookie. If the cookie is sent in requests from other sites, it can be vulnerable to cross-site request forgery (CSRF) attacks.

Check out this video for a high-level explanation:

Some of the potential consequences of using insecure cookie flags are:

  • Session hijacking: If cookies are not configured with the "Secure" flag, they can be intercepted by an attacker and used to hijack a user's session. An attacker can use the stolen cookie to impersonate the user and access sensitive information or perform unauthorized actions on the website.
  • Cross-site scripting (XSS) attacks: If cookies are not configured with the "HttpOnly" flag, they can be accessed by client-side scripts, such as JavaScript. This makes the cookie vulnerable to XSS attacks, where an attacker can inject malicious code into a website and steal the cookie.
  • Cross-site request forgery (CSRF) attacks: If cookies are not configured with the "SameSite" flag, they can be sent in requests from other sites. This makes the cookie vulnerable to CSRF attacks, where an attacker can trick a user into unknowingly performing an action on the website that the user did not intend to perform.
  • Data breaches: If cookies contain sensitive information, such as login credentials or personal data, they can be exposed in a data breach. If the cookie is not configured with the "Secure" flag, the data can be intercepted by an attacker and used for malicious purposes.

The best practices to follow for secure cookie flags are:

  • Set the "Secure" flag: This flag ensures that cookies are only transmitted over HTTPS connections. This prevents cookies from being intercepted by attackers and helps prevent session hijacking attacks. Ensure that all cookies that contain sensitive information or are used for session management are configured with the "Secure" flag.
  • Set the "HttpOnly" flag: This flag ensures that cookies are not accessible by client-side scripts, such as JavaScript. This prevents cookies from being vulnerable to cross-site scripting (XSS) attacks. Ensure that all cookies that contain sensitive information are configured with the "HttpOnly" flag.
  • Set the "SameSite" flag: This flag ensures that cookies are only sent in requests that originate from the same site as the one that set the cookie. This prevents cookies from being vulnerable to cross-site request forgery (CSRF) attacks. Ensure that all cookies that are used for session management or perform actions on behalf of the user are configured with the "SameSite" flag.
  • Use a secure cookie storage mechanism: Ensure that cookies are stored securely on the user's device and are not accessible to other applications or users. Use a secure cookie storage mechanism, such as HttpOnly cookies, to prevent cookies from being accessed or modified by attackers. Regularly review and update cookie settings: Regularly review and update cookie settings to ensure that they are up-to-date with the latest best practices and security recommendations. Ensure that all cookies are configured with the appropriate secure flags and that any cookies that are no longer needed are deleted.

References​

Taxonomies​

Explanation & Prevention​

Training​

Insecure Cookie Flags have been detected by our runtime engines.

Fixing advice for common languages is listed below:

HTTP Security Headers​

About HTTP Security Headers

What are insecure HTTP security headers?​

HTTP security headers are a set of headers that can be sent by a web server to a user's web browser to help protect against various types of attacks, such as cross-site scripting (XSS), clickjacking, and cross-site request forgery (CSRF).

These headers provide additional security controls that can help to prevent attackers from exploiting vulnerabilities in web applications.

However, if these security headers are not configured correctly, they can be vulnerable to attacks that compromise the security of a website and its users. One common vulnerability is the use of insecure HTTP security headers. Insecure HTTP security headers are settings that can be configured for a security header to specify how the header should be transmitted and stored.

Some common insecure HTTP security headers include:

  • "X-Frame-Options" header: This header is used to prevent clickjacking attacks by indicating whether a page can be displayed in an iframe. If the header is not set or is set incorrectly, a page can be vulnerable to clickjacking attacks.
  • "Content-Security-Policy" header: This header is used to prevent XSS attacks by specifying which sources of content are allowed to be loaded by a web page. If the header is not set or is set incorrectly, a page can be vulnerable to XSS attacks.
  • "X-XSS-Protection" header: This header is used to enable the browser's built-in XSS protection mechanisms. If the header is not set or is set incorrectly, a website can be vulnerable to XSS attacks.
  • "Strict-Transport-Security" header: This header is used to ensure that a website is only accessed over HTTPS connections. If the header is not set or is set incorrectly, a website can be vulnerable to man-in-the-middle attacks.
  • "Cross-Origin Resource Sharing (CORS)" headers: This header is used to protect against cross-site request forgery (CSRF) and other types of attacks. It specifies which origins, HTTP methods, and credentials are allowed to be accessed.

Check out this video for a high-level explanation:

What is the impact of insecure HTTP security headers?​

Some of the potential consequences of using insecure HTTP security headers are:

  • Increased risk of cross-site scripting (XSS) attacks: If the "Content-Security-Policy", or "X-XSS-Protection" header is not set or is set incorrectly, a website can be vulnerable to XSS attacks. This can allow attackers to inject malicious code into a website and steal sensitive information, such as login credentials or personal data.
  • Increased risk of clickjacking attacks: If the "X-Frame-Options" header is not set or is set incorrectly, a website can be vulnerable to clickjacking attacks. This can allow attackers to trick users into performing actions that they did not intend to perform, such as clicking on a button that executes a malicious action.
  • Increased risk of cross-site request forgery (CSRF) attacks: If the "Access-Control-Allow-Origin" header is not set or is set incorrectly, a website can be vulnerable to CSRF attacks. This can allow attackers to trick users into unknowingly performing actions on the website that they did not intend to perform.
  • Increased risk of data breaches: If HTTP security headers are not configured correctly, a website can be vulnerable to data breaches. This can allow attackers to steal sensitive information, such as login credentials or personal data, and use it for malicious purposes.

How to prevent insecure HTTP security headers?​

Some of the best practices to prevent insecure HTTP security headers are:

  • Set the appropriate values for HTTP security headers: Each HTTP security header has a set of valid values that can be used to configure it. Ensure that the appropriate values are set for each header to provide the desired level of protection against attacks.
  • Regularly review and update HTTP security header settings: Regularly review and update HTTP security header settings to ensure that they are up-to-date with the latest best practices and security recommendations.
  • Use tools to validate HTTP security header settings: Use tools, such as the Mozilla Observatory, to validate the configuration of HTTP security headers and ensure that they are set correctly. These tools can also provide recommendations for improving the security of a website.
  • Use a content delivery network (CDN) with built-in security features: Some CDNs offer built-in security features, such as the automatic configuration of HTTP security headers. Consider using a CDN with these features to simplify the configuration and management of HTTP security headers.

References​

Taxonomies​

Explanation & Prevention​

Training​

Fixing HTTP Security headers​

Insecure HTTP Security Headers have been detected by our runtime engines.

Fixing advice for common languages is listed below:

Last updated on by Stefan Streichsbier