Skip to content

Add Cache-Control section and clarify caching directives#2092

Open
Artemiz0307 wants to merge 1 commit intoOWASP:masterfrom
Artemiz0307:patch-1
Open

Add Cache-Control section and clarify caching directives#2092
Artemiz0307 wants to merge 1 commit intoOWASP:masterfrom
Artemiz0307:patch-1

Conversation

@Artemiz0307
Copy link
Copy Markdown

Added a Cache-Control section to the HTTP Headers Cheat Sheet.

This includes clear explanations of the no-store, no-cache, and private directives, along with recommendations for secure usage to prevent unintended caching of sensitive data.

Added section on Cache-Control header with recommendations for sensitive content caching.
The `Referrer-Policy` HTTP header controls how much referrer information (sent via the Referer header) should be included with requests.



Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small nit: looks like a couple of extra blank lines got added here. Was this intended?

- `no-cache`: Allows the response to be stored, but requires the cache to revalidate with the server before using it. This ensures that stale data is not served.

- `private`: Allows caching only in the user’s browser, but prevents storage in shared caches such as proxies.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RFC 9111 section 3.5 has specific rules about how shared caches must handle responses to requests containing an Authorization header. Since this section covers the private directive and shared caches, would it be helpful to add a note like: "Responses to requests with an Authorization header are not stored by shared caches unless explicitly allowed via public, must-revalidate, or s-maxage"? It's a common gotcha that catches people off guard


- `no-cache`: Allows the response to be stored, but requires the cache to revalidate with the server before using it. This ensures that stale data is not served.

- `private`: Allows caching only in the user’s browser, but prevents storage in shared caches such as proxies.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to add must-revalidate to the list as well? It's commonly paired with no-cache and private in practice, and without it some caches may serve stale responses after disconnecting from the origin. Something like: "must-revalidate: Once a cached response becomes stale, it must not be used without successful revalidation with the origin server."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants