Skip to content

Latest commit

 

History

History
133 lines (78 loc) · 7.15 KB

security_considerations.md

File metadata and controls

133 lines (78 loc) · 7.15 KB

Security Considerations

Overview

Security headers are a critical component of modern web application security. They help mitigate common attack vectors such as Cross-Site Scripting (XSS), clickjacking, and man-in-the-middle (MITM) attacks. This guide highlights the security implications of each header supported by secure.py and offers best practices based on OWASP recommendations.

Importance of Security Headers

Strict-Transport-Security (HSTS)

The Strict-Transport-Security header ensures that browsers only connect to your site over HTTPS, preventing MITM attacks by forcing a secure connection. It tells the browser to remember to always access the site via HTTPS, even if the user tries to access it over HTTP.

  • MDN Docs - Strict-Transport-Security
  • Best Practice: Set a long max-age (e.g., max-age=63072000 for two years) and include subdomains.
  • Pitfall: Be cautious when setting the preload directive, as it’s difficult to remove once added to the HSTS preload list.

Content-Security-Policy (CSP)

The Content-Security-Policy header helps prevent XSS and data injection attacks by specifying which content sources are allowed to be loaded by the browser. It is one of the most effective ways to mitigate XSS attacks.

  • MDN Docs - Content-Security-Policy
  • Best Practice: Start with a strict default-src 'self' policy and expand only as needed. Use nonce-based policies for inline scripts.
  • Pitfall: Overly permissive CSP rules (e.g., using unsafe-inline, unsafe-eval, or *) can leave your application vulnerable to XSS attacks.

X-Frame-Options

The X-Frame-Options header prevents clickjacking attacks by controlling whether your site can be embedded in an iframe.

  • MDN Docs - X-Frame-Options
  • Best Practice: Set to DENY to completely block framing, or SAMEORIGIN if you only want to allow framing from your own domain.
  • Pitfall: Be careful when setting SAMEORIGIN if you allow content embedding. Incorrect settings can break legitimate functionality, such as embedded dashboards or widgets.

X-Content-Type-Options

The X-Content-Type-Options header prevents MIME-sniffing by telling the browser to strictly follow the declared Content-Type. This helps prevent certain types of attacks, including drive-by downloads.

  • MDN Docs - X-Content-Type-Options
  • Best Practice: Always set this header to nosniff.
  • Pitfall: None. This header is very low-risk but high-reward from a security perspective.

Referrer-Policy

The Referrer-Policy header controls how much referrer information is included with requests. By limiting referrer data, you can prevent sensitive URL data from being exposed to third-party sites.

  • MDN Docs - Referrer-Policy
  • Best Practice: Use strict-origin-when-cross-origin to protect sensitive referrer information while preserving analytics functionality.
  • Pitfall: Using unsafe-url can expose full URLs, which may leak sensitive data.

Permissions-Policy

The Permissions-Policy (formerly Feature-Policy) header allows you to enable or disable browser features such as geolocation, camera access, and more.

  • MDN Docs - Permissions-Policy
  • Best Practice: Disable unnecessary features (e.g., camera, microphone, geolocation) to reduce attack surface.
  • Pitfall: Incorrectly blocking required features may break functionality like video conferencing or map-based services.

Cross-Origin-Embedder-Policy (COEP)

The Cross-Origin-Embedder-Policy header prevents a document from loading any cross-origin resources that don’t explicitly grant the document permission.

  • MDN Docs - Cross-Origin-Embedder-Policy
  • Best Practice: Use require-corp to ensure that all embedded resources are loaded securely.
  • Pitfall: Misconfiguration can prevent legitimate cross-origin resource sharing.

Cross-Origin-Opener-Policy (COOP)

The Cross-Origin-Opener-Policy header helps isolate your browsing context by preventing access to your global object via cross-origin documents.

  • MDN Docs - Cross-Origin-Opener-Policy
  • Best Practice: Set this to same-origin to protect against XS-Leaks and ensure that only same-origin documents can access the browsing context.
  • Pitfall: Incompatibility with certain cross-origin interactions, such as embedded third-party services.

Cache-Control

The Cache-Control header controls how and for how long browsers cache responses. Setting it properly can prevent sensitive data from being stored in caches.

  • MDN Docs - Cache-Control
  • Best Practice: Use no-store for sensitive pages like login or payment forms to ensure that they are not cached.
  • Pitfall: Improper caching of sensitive data can lead to exposure of private information.

Server

The Server header is typically used to reveal information about the server software being used. Hiding or customizing this header can obscure specific server details from attackers.

  • MDN Docs - Server
  • Best Practice: Either remove or set this to a generic value to avoid exposing server details.
  • Pitfall: Leaving this header exposed can give attackers valuable information about your server’s configuration, potentially making it easier to exploit.

Custom Headers

In addition to the predefined headers, you can define custom security headers based on your application's specific needs.

  • Best Practice: Use custom headers for non-standard security requirements or business-specific security mechanisms.

Common Pitfalls

  • Improper CSP Configurations: Using unsafe-inline or unsafe-eval weakens CSP protections and should be avoided.
  • Weak HSTS Settings: A short max-age value undermines the effectiveness of HSTS, as users will not remain protected if the connection is downgraded.

OWASP Guidelines

For further recommendations on security headers, refer to the OWASP Secure Headers Project.

Attribution

This library implements security recommendations from trusted sources: