HTTP Security Considerations (WIP)

The HTTP protocol is the core of web communication, whose functioning has been covered in the protocols section. For this reason is critical to implement practices that help to keep this environment secure.

We can find HTTP response headers and client-side security controls that help protect modern web applications from common vulnerabilities. Properly configuring these mechanisms reduces the attack surface by restricting how browsers and servers interpret, store, and execute content.

For testing web applications, it is necessary to understand these practices to review their implementation and flaws in web applications.

Content Security Policy

CSP and X-Content-Type-Options to prevent MIME-type sniffing attacks

Cookie Security Flags

Security flags are a relevant configuration for HTTP cookies. They control the behavior, accessibility, and security of cookies sent between the client and the server. They are set on the server via the Set-Cookie HTTP response header, which includes instructions for the browser on how to handle cookies.

Here we explain some of the security flags that can be controlled:

• Secure: The cookie can only be sent over HTTPS connections (not HTTP). It is mandatory if the SameSite=Strict flag is set Example: Set-Cookie: sessionid=123; Secure

• HttpOnly: The cookie is not accessible by JavaScript (document.cookie), which helps prevent XSS attacks. Example: Set-Cookie: sessionid=123; HttpOnly

• SameSite: Restricts cookie cross-site requests, which helps prevent CSRF. It can be set as Strict, Lax, or None. Example: Set-Cookie: sessionid=123; SameSite=Strict

  • Strict: The cookie is only sent if the request comes from the same site; any request initiated by a link or request from an external domain will not include the cookie

  • Lax: The cookie is sent in some cross-site navigation situations (for example, when clicking on a link), but not in automatic requests such as image uploads or third-party AJAX requests

  • None: The cookie is sent in all circumstances, including cross-site requests. When using this, it is mandatory to mark the cookie as Secure

• Domain: Specifies which hosts/domains can receive the cookie. Example: Set-Cookie: sessionid=123; Domain=.site.com

• Path: Specifies the URL path that must exist in the request to send the cookie. Example: Set-Cookie: sessionid=123; Path=/admin

• Expires/Max-Age: Sets how long the cookie persists in the client. Example: Set-Cookie: sessionid=123; Max-Age=3600

Frame Headers

X-Frame-Options or Frame-Ancestors (to prevent clickjacking),

Referrer Policy

to limit sensitive URL leakage

Permissions Policy

to control access to powerful browser features