单页应用（SPA）中如何保障访问凭证的安全？

Great question—this cuts to a core pain point with SPAs, since they run entirely in the browser with no backend to shield sensitive data. Let’s start with general security mechanisms for SPAs, then dive into solving the specific hosts file spoofing scenario you described.

General SPA Credential Security Mechanisms #

First, let’s cover foundational practices to keep tokens safe in any SPA:

• Use Short-Lived Access Tokens: Issue access tokens (like JWTs) with a short expiry window (15–30 minutes). Even if a token is stolen, the attacker’s window to misuse it is limited. Pair this with refresh tokens to avoid forcing users to re-authenticate constantly.
• Leverage Authorization Code Flow with PKCE: Ditch the outdated Implicit Flow—PKCE (Proof Key for Code Exchange) is non-negotiable for SPAs. It generates a unique code_verifier per authentication request; even if an attacker intercepts the authorization code, they can’t exchange it for a token without this verifier.
• Store Tokens Safely: Avoid localStorage (it’s vulnerable to XSS attacks). Instead:
  • Store refresh tokens in HttpOnly, Secure, SameSite=Strict/Lax cookies: These are inaccessible to JavaScript, so XSS scripts can’t steal them.
  • Keep access tokens in memory (e.g., React state, Vue refs) instead of persistent storage. They’ll be cleared when the tab closes, reducing exposure.
• Validate Token Claims Rigorously: Your microservices must always verify critical JWT claims:
  • iss: Ensures the token came from your trusted identity provider (IdP).
  • aud: Confirms the token was intended for your specific API/microservice.
  • exp: Checks that the token hasn’t expired.
• Mitigate XSS Risks: Use Content Security Policy (CSP) to restrict which scripts can run on your SPA, sanitize all user input, and avoid unsafe DOM methods (like innerHTML). XSS is the most common way attackers steal tokens in SPAs.

Addressing the Hosts File Spoofing Scenario #

In your scenario, the attacker modifies /etc/hosts to map localhost to https://example.com, then uses stolen tokens to impersonate your SPA. Here’s how to block this:

• Enforce azp (Authorized Party) Claim Validation: When your IdP issues tokens, include the azp claim to specify the exact client ID of your SPA. Your microservices must check that the azp value matches your registered SPA client ID. The attacker’s local app won’t have this valid client ID, so even with a stolen token, the microservices will reject the request.
• Validate Request Origins: Configure your microservices to check the Origin header of incoming requests. Only allow requests from your official SPA origin (https://example.com). While the attacker’s spoofed setup makes the browser send https://example.com as the Origin, edge cases (like if the attacker uses a file:// URL) will fail this check. Combine this with token claim validation for added safety.
• Use Token Binding (Where Supported): Some IdPs support token binding, which ties a token to a specific TLS session or device identifier. If the attacker tries to use the token in a different session (their local app), the microservices will detect the mismatch and reject the request.
• Avoid Persistent Token Storage: As mentioned earlier, keep access tokens in memory instead of localStorage or cookies. If the attacker steals a token that’s only in memory, it will be invalid once the original SPA tab is closed—they can’t reuse it indefinitely.
• Implement Real-Time Token Introspection: Have your microservices call your IdP’s token introspection endpoint on every request to check if the token is still valid (e.g., revoked due to suspicious activity). If you detect the token being used from an unusual location/device, revoke it immediately.

Pro Tip: Never pass credentials in URL parameters (like your example’s ?secure=maybe). URLs are logged in browser history, server logs, and proxy records—making them easy targets for theft.

内容的提问来源于stack exchange，提问作者Ole