TLS termination & proxies
21A TLS-terminating proxy becomes part of the security boundary. Forwarded headers and the internal hop need protection too.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.13 ↗
RFC 9700 · § 4.13DEFENSE
3 / 3
03
Make decisions using authenticated facts.
The application receives security context only through its trusted proxy boundary.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
Read the updated RFC section ↗
Sanitize headers. Secure the internal hop.
- Proxies MUST sanitize inbound requests to preserve authenticity and integrity of security-relevant headers.
- Do not trust client-supplied forwarded IP, client certificate, or token-binding information as proxy-authenticated facts.
- The proxy-to-application link MUST prevent eavesdropping, message injection, and replay, with authenticated communicating entities.
A spoofed X-Forwarded-For value can defeat an IP-based policy if the app interprets it as trusted. Outside TLS does not authenticate attacker-controlled header contents.
Read the RFC section ↗Diagrams simplify the RFC. Read the linked sections for complete requirements.
PrivacyAll chapters in this RFC
- OAuth overview
- Authorization code + PKCE
- Retire unsafe grants
- Prevent token replay
- Limit token privileges
- Authenticate the client
- Metadata, TLS & CORS
- The attacker model
- Redirect URI validation
- Referer header leakage
- Browser history leakage
- Authorization server mix-up
- Authorization code injection
- Access token injection
- Cross-site request forgery
- PKCE downgrade
- Leakage at resource servers
- Misuse of stolen tokens
- Open redirection
- 307 credential forwarding
- TLS termination & proxies
- Refresh token protection
- Client as resource owner
- Clickjacking
- In-browser messaging