Skip to main content

6. Security Considerations

6. Security Considerations​

Applications using HTTP need to carefully consider security. This section highlights some key security considerations; see also [HTTP] Section 17.

Applications SHOULD use TLS [RFC8446] for all communication. In particular, applications MUST use TLS when transmitting sensitive information such as authentication credentials or personal data. See [RFC7258] for more information about the need for ubiquitous encryption.

Applications SHOULD use the "https" URI scheme rather than "http" to ensure that TLS is used. When TLS is used, applications SHOULD follow current best practices, including:

  • Using TLS 1.3 [RFC8446] or later.

  • Validating server certificates.

  • Using appropriate cipher suites.

  • Considering the use of HTTP Strict Transport Security (HSTS) [RFC6797] to ensure that browsers always use HTTPS.

Applications need to be aware of various Web-based attacks and how to mitigate them:

  • Cross-Site Scripting (XSS): If an application returns content that can be interpreted as HTML or JavaScript by a browser, it needs to properly escape or sanitize that content to prevent XSS attacks. Using Content-Type appropriately and setting Content-Security-Policy [CSP] headers can help.

  • Cross-Site Request Forgery (CSRF): Applications that maintain state (e.g., using cookies) need to protect against CSRF attacks, where a malicious site tricks a user's browser into making requests to the application. Common mitigations include using CSRF tokens and checking the Origin or Referer header fields.

  • Injection attacks: Applications that incorporate user input into queries, commands, or other structured data need to properly validate and sanitize that input to prevent injection attacks (e.g., SQL injection).

  • Information disclosure: Applications need to be careful about what information they include in error messages, header fields, and other responses. Detailed error messages can help attackers understand the application's internals.

Applications SHOULD consider the security implications of caching. In particular:

  • Sensitive information SHOULD NOT be cached, or if it must be cached, it should only be cached privately (using Cache-Control: private).

  • Authentication credentials SHOULD NOT be included in URLs, as they might be logged or cached.

Applications using authentication need to consider:

  • How authentication credentials are transmitted (they should be protected by TLS).

  • How long authentication sessions last and how they can be revoked.

  • How to protect against brute-force attacks on authentication.

  • Whether multi-factor authentication is appropriate.

Applications SHOULD be aware that clients and servers might not be under the control of the application's designers. In particular:

  • Intermediaries (proxies, CDNs, etc.) might cache, log, or modify requests and responses.

  • Clients might be malicious or compromised.

  • Servers might be compromised.

Applications SHOULD therefore:

  • Use end-to-end encryption and authentication where appropriate.

  • Not rely solely on transport-layer security for sensitive operations.

  • Validate all input from clients.

  • Be aware of the principle of least privilege and avoid giving clients or servers more access than necessary.

Applications that allow users to upload content or execute code need to be extremely careful about sandboxing and isolation. Even seemingly benign features can be abused:

  • File uploads might contain malicious content that could exploit vulnerabilities in parsers or viewers.

  • User-controlled URLs might be used for Server-Side Request Forgery (SSRF) attacks.

  • Features that execute user-provided code (e.g., JavaScript in a browser context) need strong isolation.

Applications that are accessible from Web browsers need to be particularly careful because browsers have a complex security model with many potential pitfalls. Applications SHOULD:

  • Use appropriate Content-Security-Policy headers [CSP] to limit what browsers can do.

  • Use appropriate CORS policies [FETCH] to control cross-origin access.

  • Set cookies with appropriate flags (Secure, HttpOnly, SameSite).

  • Consider using X-Frame-Options or CSP's frame-ancestors directive to prevent clickjacking.

  • Be aware of browser-specific behaviors such as prefetching, DNS prefetching, and preconnecting.

  • Consider using Subresource Integrity (SRI) to ensure that externally-hosted resources haven't been tampered with.

Applications SHOULD be aware that HTTP features can sometimes be abused:

  • Redirects can be used for phishing or to bypass security controls.

  • Large requests or responses can be used for denial-of-service attacks.

  • Complex parsing of header fields or content can lead to vulnerabilities.

Finally, applications SHOULD have a clear security policy and should be designed with security in mind from the beginning. Security should not be an afterthought.

Last updated on