Why this matters
Limiting token lifetime and storage reduces scope and lateral risk.
Accept only short-lived tokens from the gateway (JWT/JWE or opaque) and validate signature/expiry; do not persist tokens beyond business need. Never attempt to reconstruct PAN from tokens. (PCI DSS data minimization)
Limiting token lifetime and storage reduces scope and lateral risk.
Side-by-side examples engineers can pattern-match during review.
store.save({ token: tokenFromGateway, ttlDays: 365 }) // ❌const t = parseAndVerify(tokenFromGateway, gwJwkSet);
if (t.exp < now()+560) throw new Error("token too short");
store.saveEphemeral(t.id, 900); // 15 minpersist(token, ONE_YEAR)verify(token) && saveEphemeral(id, 900)From the same buckets as this rule.
Never emit Primary Account Number (PAN) or Sensitive Authentication Data (SAD: CVV/CVC, full track data, PIN) to application or audit logs. Per PCI DSS 4.0 Req. 3 and 10, always mask PAN as first6last4 and fully redact SAD before logging.
Reject PRs adding real PAN/CVV in fixtures, seeds, or mocks. Only use Luhn-valid test PANs from the gateway or opaque tokens (e.g., tok_) and never include CVV. Add a check to fail if a PAN regex is matched. (PCI DSS data minimization)