HTTP caching for web APIs — Cache-Control headers, ETags, conditional requests,
88
84%
Does it follow best practices?
Impact
100%
25.00xAverage score across 4 eval scenarios
Passed
No known issues
{
"instruction": "Use 'private, no-store' (not just no-cache) on endpoints that return authenticated or sensitive user data, and set Vary: Authorization",
"relevant_when": "Agent creates any API endpoint that requires authentication, returns user-specific data, or serves sensitive information like profiles, account details, tokens, or payment data — even if the task does not mention caching or security",
"context": "no-cache means 'cache it but revalidate before using' — the response is still stored on disk. For sensitive data this is a security risk. no-store means 'never write this to any cache.' Authenticated endpoints must also set 'private' to prevent CDNs from caching and serving one user's data to another. Vary: Authorization tells caches that the response differs per user.",
"sources": [
{
"type": "file",
"filename": "skills/http-caching-strategy/SKILL.md",
"tile": "tessl-labs/http-caching-strategy@0.2.0"
}
],
"checklist": [
{
"name": "no-store-on-sensitive-data",
"rule": "Endpoints returning user profiles, account details, tokens, API keys, or payment information set 'Cache-Control: private, no-store' — NOT just 'no-cache'",
"relevant_when": "Agent creates endpoints that return sensitive or personally identifiable data"
},
{
"name": "vary-authorization-on-auth-endpoints",
"rule": "Endpoints that require authentication set 'Vary: Authorization' so caches maintain separate entries per user",
"relevant_when": "Agent creates endpoints behind authentication middleware"
},
{
"name": "private-on-user-specific-data",
"rule": "Endpoints returning per-user data include 'private' in Cache-Control to prevent shared caches (CDNs, proxies) from storing the response",
"relevant_when": "Agent creates endpoints that return different data depending on which user is authenticated"
}
]
}