Source: [AI-written caches: test who can receive a reused response — Skills for Business](<https://skillsforbusiness.ai/blog/ai-written-caches-response-access-boundaries/>)

[← All articles](https://skillsforbusiness.ai/blog/)

Development · Guide

# AI-written caches: test who can receive a reused response

Review AI-generated caching code with account, permission and request-variant cases. A faster dashboard must preserve the access rules of an uncached response.

[Skills for Business](https://skillsforbusiness.ai/blog/editorial/)3 November 20267 min read

On this page

1.  [Define the permitted sharing group first](https://skillsforbusiness.ai/blog/ai-written-caches-response-access-boundaries/#define-the-permitted-sharing-group-first)
2.  [Trace identity through the cache-hit path](https://skillsforbusiness.ai/blog/ai-written-caches-response-access-boundaries/#trace-identity-through-the-cache-hit-path)
3.  [Include request variants that change the answer](https://skillsforbusiness.ai/blog/ai-written-caches-response-access-boundaries/#include-request-variants-that-change-the-answer)
4.  [Separate HTTP policy from application storage](https://skillsforbusiness.ai/blog/ai-written-caches-response-access-boundaries/#separate-http-policy-from-application-storage)
5.  [Use an ordered request matrix](https://skillsforbusiness.ai/blog/ai-written-caches-response-access-boundaries/#use-an-ordered-request-matrix)
6.  [Keep freshness and access changes distinct](https://skillsforbusiness.ai/blog/ai-written-caches-response-access-boundaries/#keep-freshness-and-access-changes-distinct)
7.  [Sources](https://skillsforbusiness.ai/blog/ai-written-caches-response-access-boundaries/#sources)

What to take away

-   Define which requests may share a response before choosing its cache key.
-   Test account and permission boundaries with warm caches in both request orders.
-   Review application caches and HTTP caches separately; one header does not configure every storage layer.

When an AI coding assistant adds caching to a business application, review who can receive the saved response before measuring the speed improvement. A cache entry that is correct for one request may be wrong for another account, permission level or filter. Reusing it must preserve the application’s access rules.

Start by defining which requests are allowed to share an answer. Then trace how the generated code identifies the requester, selects an entry and checks permission before serving it. Test the result after another requester has already populated the cache. A cold-cache demonstration cannot establish that reuse is safe.

This guide proposes a review of a fictional service dashboard. No cache implementation, assistant, CDN account or vulnerability scanner was tested for this article. The examples are acceptance cases for a team’s controlled test environment, not observed security results.

## Define the permitted sharing group first

Imagine a fictional service provider with two customer accounts, North and South. Both use the same dashboard route to view their open requests. Within North, a coordinator can see the whole account while an ordinary member sees only assigned requests. The owner has approved those visibility rules before the performance change begins.

The assistant proposes saving the dashboard’s JSON response under its URL for a short interval. That may improve repeated access, but the URL alone does not express the approved visibility rules in this example. If North populates the entry and South receives it, the saved data crosses an account boundary. If a member receives the coordinator’s response, the account boundary remains intact while the permission boundary fails.

Write the sharing condition in business terms: which requesters, scopes and request variants may receive the same representation? Do not settle for “include tenant ID.” Two people in the same tenant may have different effective visibility. Conversely, adding every possible input to a key can create unnecessary entries without establishing correct authorization.

Resolve the rule with the application owner, then map it to the implementation. If the team cannot explain the sharing condition, keep that response out of the proposed shared cache until it can.

## Trace identity through the cache-hit path

Review the route followed when the entry already exists. Generated code can preserve the usual authorization checks on a database query while returning a cached response before reaching those checks. The ordinary page may therefore behave correctly on a miss and incorrectly on a hit.

Ask the assistant to identify the cache lookup, the first return of cached content and the checks governing that return. Inspect the code and middleware yourself or through the team’s normal review process. The presence of an authorization helper elsewhere in the handler does not show that the hit path reaches it.

The identity used for selection must come from the application’s verified request context. An unchecked account identifier supplied in a query string is not permission to receive that account’s data. Do not solve a collision by trusting a new client-controlled header containing a preferred role.

Treat key construction and authorization as related decisions with separate evidence. A more detailed key can separate stored representations, but it does not establish that the caller may select one. Record where access is checked and how the cached representation is associated with the allowed visibility scope.

## Include request variants that change the answer

In the fictional dashboard, a filter can select assigned requests or all requests permitted to the current viewer. A language setting changes labels. A reporting interval changes the counts. Decide which differences change the reusable representation and verify that the cache distinguishes or deliberately excludes them.

Cloudflare’s current [cache-key documentation](https://developers.cloudflare.com/cache/how-to/cache-keys/) illustrates the consequences of configuration choices: query parameters can be included or excluded, and an Ignore Query String configuration can make different query values share a key. This is product documentation, not evidence about the fictional application or a recommendation to enable that configuration.

For generated application code, inspect the actual normalization too. Are missing and empty filters equivalent under the route’s contract? Does changing parameter order preserve meaning? Does a normalized key omit a field that still changes the query? Do not let a cleanup function silently define these semantics.

Keep the proposed cases small and explicit. Start with the inputs known to affect the response, then review the surrounding route for additional variation. A cache key is a claim that some requests can reuse the same result; make that claim reviewable.

## Separate HTTP policy from application storage

An application may have an in-process result map, a shared data store, a reverse proxy, a CDN and a browser cache. Identify which layer the assistant changed and which other layers can retain the response. A response header does not automatically change the behavior of an arbitrary application cache.

[RFC 9111, published in June 2022](https://www.rfc-editor.org/rfc/rfc9111.html), distinguishes private and shared HTTP caches. Its unqualified `private` response directive prohibits storage by a shared cache while allowing private-cache storage subject to other constraints. `no-store` directs caches not to store the request or response or reuse the response, with limitations discussed in the specification. These directives are not interchangeable, and neither should be described as a complete access-control system.

Apply the actual framework and infrastructure documentation to the intended deployment. Confirm the effective rules rather than assuming development behavior matches production. Where the response must remain uncached, verify both that it is not served from an existing entry and that the relevant layer does not create a reusable entry during the test.

## Use an ordered request matrix

For the fictional dashboard, the following are proposed checks with synthetic records and isolated test accounts. Mark North-only and coordinator-only records clearly so a reviewer can recognize an unauthorized response without using real customer data.

| Controlled sequence | What to inspect |
| --- | --- |
| North populates the cache; South requests the same route | South receives only its permitted records |
| South populates it; North requests next | North receives the correct North representation |
| North coordinator populates it; North member requests next | Coordinator-only records remain absent for the member |
| Authenticated viewer populates it; logged-out request follows | No private response reaches the logged-out requester |
| One filter or reporting interval populates it; another follows | The result matches the later request’s documented meaning |
| Access is removed while an entry remains reusable | The application’s chosen revocation policy is enforced |
| Cache is unavailable or an entry expires | The fallback preserves the same access and response rules |

Compare each response with the expected result for that requester. Where possible, use a controlled uncached reference path to help detect differences, while checking that the reference itself implements the agreed rule. A matching status code or a cache-hit header is not a sufficient assertion.

Exercise the real request path and intended cache layer. A unit test that calls only the data-fetching function may never reach the faulty early return. Record request order, identity, fixture state, active configuration, response and evidence of reuse. Repeat the important pairs in the reverse order so the test does not accidentally depend on which user arrived first.

## Keep freshness and access changes distinct

A short expiry limits how long an entry is eligible for reuse. It does not determine who may receive it during that interval. Likewise, a correctly separated account key does not decide what happens after someone’s access is revoked or their assigned work changes.

Specify that behavior before accepting the optimization. The owner may require a fresh permission check, reliable invalidation, a changed visibility version or exclusion from caching. The appropriate mechanism depends on the application; this guide does not prescribe one universal key format or acceptable delay.

Historical research reinforces the need to inspect more than appearance. In [Web Cache Deception Escalates!, published at USENIX Security 2022](https://www.usenix.org/conference/usenixsecurity22/presentation/mirheidari), researchers combined content comparison and cache-header heuristics to investigate erroneous web caching. Their work concerns web cache deception, not AI-written application caches. Its historical prevalence results do not estimate the risk in a current product or validate this proposed matrix.

Cloudflare’s [April 2017 practitioner explanation](https://blog.cloudflare.com/understanding-our-cache-and-the-web-cache-deception-attack/) similarly discusses mismatches between application routing and cache decisions. It is a vendor’s historical technical account; use current documentation for current configuration. The blog and cache-key documentation are from the same publisher, not independent evidence of product effectiveness.

Start with one generated caching change. Review its sharing condition, inspect the hit path and run the ordered cases before accepting the performance benefit. Keep unresolved cases visible. Our [guide to checking AI-generated tests](https://skillsforbusiness.ai/blog/ai-generated-tests-intended-regression/) covers whether an assertion notices its intended failure; here, the failure to expose is a response reused outside the access or representation boundary that made it correct.

## Sources & further reading

Sources checked for this article. Research findings and vendor claims are distinguished in the text.

1.  [RFC 9111: HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111.html)IETF; Fielding, Nottingham and Reschke · Accessed 3 November 2026
2.  [Cache Keys](https://developers.cloudflare.com/cache/how-to/cache-keys/)Cloudflare documentation · Accessed 3 November 2026
3.  [Web Cache Deception Escalates!](https://www.usenix.org/conference/usenixsecurity22/presentation/mirheidari)Mirheidari et al.; USENIX Security 2022 · Accessed 3 November 2026
4.  [Understanding Our Cache and the Web Cache Deception Attack](https://blog.cloudflare.com/understanding-our-cache-and-the-web-cache-deception-attack/)Joshua Liebow-Feeser; Cloudflare · Accessed 3 November 2026

Produced with AI-assisted research and writing. Examples and recommendations are our editorial synthesis unless attributed. This article does not claim independent product testing or human expert review. [Read our editorial policy.](https://skillsforbusiness.ai/blog/editorial/)

## Keep reading

[AI-written webhook handlers: verify the request before changing the record](https://skillsforbusiness.ai/blog/ai-written-webhook-handlers-signature-boundary/)[AI-written list endpoints: test the boundary between pages](https://skillsforbusiness.ai/blog/ai-written-list-endpoints-pagination-boundaries/)