This chapter focuses on hardening OAuth-protected resource servers against common attacks. It explains how access tokens can leak or be abused (through hijacking, weak entropy, or overly broad scopes) and shows why resource endpoints are frequent targets for cross-site scripting. A central theme is designing endpoints that minimize token spoofing and replay risk while leveraging modern browser protections to reduce the likelihood and impact of client-side exploits.
The text walks through practical endpoint design choices that curb XSS: never reflect untrusted input without sanitization/encoding; favor structured responses with the correct Content-Type (for example, application/json) to prevent script execution; and add protective headers such as X-Content-Type-Options: nosniff and X-XSS-Protection, with Content Security Policy as an additional hardening layer. It also recommends avoiding access_token in query parameters in favor of the Authorization: Bearer header, reducing an attacker’s ability to craft malicious, token-bearing links. Together, correct output handling, media types, and security headers substantially raise the bar against injection and reflection bugs.
For browser-based clients (such as those using the implicit grant), the chapter addresses the Same Origin Policy by enabling CORS at the resource endpoint, allowing controlled cross-origin calls instead of relying on legacy JSONP patterns. To limit token replay, it emphasizes short token lifetimes and end-to-end transport security, advocating TLS everywhere and reinforcing it with HTTP Strict Transport Security to prevent downgrades and mixed-content mistakes. The combined guidance—careful output handling, precise Content-Type, judicious use of browser security headers, prudent token handling, CORS where appropriate, and mandatory TLS with HSTS—provides a practical blueprint for defending common protected resource vulnerabilities.
Access token with greeting scope
Greeting in English
Greeting in German
Invalid language
XSS in the protected resource endpoint
Sanitized response in the protected resource endpoint
Content-Type application/json in the protected resource endpoint
Same Origin Policy issue
Protected resource with CORS enabled
FAQ
What are the most common vulnerabilities in OAuth-protected resources?
Access tokens can leak (through hijacking, weak entropy, or overly broad scopes), and endpoints can be vulnerable to XSS—especially when they reflect untrusted input or accept access_token as a URI parameter.Why is passing access_token as a query parameter risky?
It can expose tokens via referrers, logs, and browser history, and it enables attackers to craft malicious links that both include a token and trigger XSS. Prefer the Authorization: Bearer header.How do I prevent XSS in my resource endpoints?
Always sanitize/escape untrusted output, set an appropriate Content-Type (often application/json), avoid reflecting raw input, and consider CSP. Combine these with security headers for defense in depth.Which response headers help mitigate XSS risks?
Use Content-Type (e.g., application/json), X-Content-Type-Options: nosniff, and X-XSS-Protection: 1; mode=block. A Content-Security-Policy header can further reduce XSS risk.How does the Content-Type header influence XSS exposure?
Serving JSON (application/json) causes browsers to treat responses as data rather than executable HTML/JS, which blocks many reflected XSS attempts—even if the payload appears in the JSON string. Still sanitize output.When and how should I enable CORS on a protected resource?
For browser-based (implicit) clients making cross-origin AJAX calls, enable CORS on the API (handle OPTIONS and set Access-Control-Allow-Origin). The example uses “*”; in practice, restrict origins where possible.Why avoid JSONP on protected resources?
JSONP sidesteps the same-origin policy by executing responses as scripts, which has led to exploits (e.g., Rosetta Flash). CORS is the safer, standards-based alternative.What is token replay and how can I reduce the risk?
Token replay is reuse of a stolen access token. Mitigate by making tokens short-lived, enforcing TLS everywhere, and using HSTS to prevent protocol downgrade and mixed-content risks.What does HSTS do for a protected resource?
Strict-Transport-Security instructs browsers to use HTTPS only, preventing downgrade to HTTP and reducing opportunities for interception and token leakage.What are the key best practices for securing protected resources?
- Sanitize all untrusted output- Set the correct Content-Type
- Add security headers (nosniff, XSS protection, consider CSP)
- Enable CORS when browser clients need it
- Avoid JSONP
- Always use TLS, ideally with HSTS
OAuth 2 in Action ebook for free
