Application acceleration is the set of techniques that make web applications respond faster: caching responses, compressing headers, multiplexing requests on one connection and shortening encrypted handshakes. Each one carries a security trade-off, including cache poisoning, cached secrets and replayable early data, so configure them deliberately.
What techniques does it include?
Four standards cover most of what acceleration means for web traffic.
Caching. RFC 9111 defines HTTP caches and the header fields that control them. A cache keeps a response and reuses it for later requests, so the origin server does less work and users wait less. A shared cache stores responses for reuse by more than one user, and is usually a proxy or content delivery layer.
Multiplexing and compression. HTTP/2 (RFC 9113) is described as enabling more efficient use of network resources and reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.
Faster transport. HTTP/3 (RFC 9114) maps HTTP onto QUIC, which offers stream multiplexing, per-stream flow control and low-latency connection establishment.
Faster encryption setup. TLS 1.3 (RFC 8446) added an optional zero round-trip time (0-RTT) mode, saving a round trip at connection setup for some application data, at the cost of certain security properties.
Commercial products bundle these ideas, often adding load balancing, TLS offload and image optimization. The principles are the same.
What does caching risk?
RFC 9111's security section is unusually direct. Caches expose an additional attack surface because the contents are an attractive target, and since contents persist after the request ends, an attack on the cache can reveal information long after a user thinks it is gone. Cache contents need to be protected as sensitive information.
It names three specific problems:
- Cache poisoning. Storing malicious content in a cache extends an attacker's reach to many users, especially with shared caches. One common vector is exploiting differences in how proxies and user agents parse messages.
- Timing attacks. Because a cache's purpose is speed, fast loads can leak which resources were previously requested. RFC 9111 describes mitigating this by adding more information to the cache key, such as the referring site, which is sometimes called double keying.
- Caching of sensitive information. Deployment flaws, often from misunderstanding how caches operate, can cause sensitive responses to be stored where others can reach them. The no-store directive tells caches not to store a response at all.
What does 0-RTT risk?
TLS 1.3's 0-RTT mode lets a returning client send application data in its first flight. The RFC is clear that there are no guarantees of non-replay between connections for that data, so it has weaker guarantees than ordinary 1-RTT data. An attacker can capture 0-RTT data and send it again. That matters if the request changes state, such as a payment or an account change.
A constructed example
A shop puts a shared cache in front of its site to survive a sale. An account page returns personalized content and the developers forgot to mark it as non-cacheable. The cache stores the first customer's page and serves it to the next visitor who requests the same URL. Speed improved and so did the damage. A header marking such responses no-store, plus a test that logs in as two users and compares pages, would have caught it. This scenario is invented; RFC 9111 describes the class of flaw.
A second case: the same shop enables 0-RTT on its API gateway. A captured "place order" request is replayed and creates a duplicate order. The fix is to allow early data only for safe, repeatable requests.
How to check or apply this
- List which layers cache or accelerate your traffic: browser, content delivery layer, reverse proxy, application server.
- Set explicit cache rules per route. Anything personalized or authenticated should be marked non-storable for shared caches.
- Test with two different users to confirm one never receives the other's content.
- Review cache keys, and make sure varying inputs such as host, language or cookies are included where they change the response.
- Allow TLS early data only for idempotent requests, and add replay protection where it must be on.
- Keep proxies and servers consistent in how they parse requests, since mismatches enable poisoning.
- Monitor cache hit rates and unusual cached responses, and know how to purge quickly.
Quick check
Is it safe to cache everything that is fast to serve?
No. Responses containing personal or session data must not sit in shared caches. Mark them non-storable and test.
Does HTTP/3 make a site more secure?
It is mainly a performance and transport change. Encryption is part of QUIC, but application flaws such as bad cache rules remain.
Sources
Last reviewed: 18 October 2026.
