使用AWS Amplify时，如何防范第三方JavaScript窃取JWT？

Great question—this is a critical security concern for any single-page application (SPA) relying on token-based authentication, especially when untrusted third-party scripts are involved. Let’s break down your two core questions and walk through Amplify’s defenses:

Can Stolen JWT Tokens Access Protected Content? #

Short answer: Yes, absolutely—if the tokens are still valid. Here’s why:

• Access Tokens: These are explicitly designed to grant access to protected AWS resources (like API Gateway, S3) or your custom backend APIs. Since you verified the token signature, it’s cryptographically valid, so any service trusting your Cognito user pool will accept it as long as it’s within its expiry window (default is 1 hour).
• ID Tokens: While primarily meant for user identity information, if your backend uses ID tokens for authorization checks (we don’t recommend this—stick to access tokens for authorization), a stolen ID token could also be used to impersonate the user.

The fact that your test script could read these tokens from localStorage confirms they’re exposed to any running JavaScript on the page, including malicious ones.

AWS Amplify’s Defenses Against Token Theft #

Amplify has several built-in mechanisms to mitigate this risk, especially in newer versions:

• HttpOnly & Secure Cookie Storage (Default in Amplify Auth v6+)
  The biggest upgrade in Amplify v6 is that it no longer stores tokens in localStorage by default. Instead, it uses HttpOnly, Secure, SameSite cookies for both access and refresh tokens. Since HttpOnly cookies are inaccessible to JavaScript, third-party scripts can’t read them—even if injected into your page. This eliminates the exact attack vector you demonstrated.

• Short-Lived Access Tokens + Secure Refresh Tokens
  Access tokens have a short default expiry (1 hour), limiting the window of opportunity if one is stolen. Refresh tokens, which are used to fetch new access tokens, are also stored in HttpOnly cookies—your frontend JavaScript never touches them. Amplify handles the refresh process silently in the background without exposing sensitive tokens to the page’s JS context.

• Content Security Policy (CSP) Support
  Amplify integrates smoothly with CSP rules, which you can enforce to restrict which scripts are allowed to run on your page. By whitelisting only trusted script sources (and blocking unknown ones like example.com), you can prevent malicious third-party scripts from being loaded in the first place—stopping token theft at the source.

• Token Validation & Restrictions
  You can harden your Cognito user pool to add extra layers of protection:

  • Configure token audience (aud) and issuer (iss) checks in your backend. This ensures even a stolen token can’t be used against services not intended for your app.
  • Enable token revocation in Cognito’s app client settings, so you can invalidate compromised tokens if a breach is detected.
  • Attach IAM policies to restrict what an access token can do (e.g., only allow access to specific API endpoints), limiting the damage of a stolen token.

• Secure Storage for Legacy Versions
  If you’re stuck on Amplify v5 or earlier (which defaults to localStorage), you can configure Amplify to use its SecureStorage module. On web, this falls back to encrypted localStorage where supported, but it’s not as secure as HttpOnly cookies. Upgrading to v6 is strongly recommended for web apps.

Quick Fix for Your Test Scenario #

If you’re using Amplify v6, double-check your auth configuration—tokens should automatically be stored in HttpOnly cookies, making your test script unable to read them. For v5, you can override the storage mechanism to use cookies (requires manual setup) or prioritize upgrading to v6.

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