Imperva API Security: Authentication Risk Report—Key Findings & Fixes

Posted on

An in-depth analysis of common JSON Web Token (JWT) mistakes, basic auth, long-lived tokens, and quick, high-impact fixes to secure your APIs.

Introduction

APIs are the backbone of modern digital services—from mobile apps and e-commerce to banking and IoT. That scale and utility also make them prime targets. In our recent study of authentication-related findings across customers, the Imperva API Security team saw a consistent pattern: small auth misconfigurations create big exposure.

Below we summarize the top authentication risks we observed, why they happen, and practical remediation steps teams can apply immediately.

Key findings (share of all auth vulnerabilities)

auth risk distribution

Figure: Auth Risk Distribution

  1. JSON Web Token (JWT) containing sensitive data — 46%
    Developers commonly put names, contact details, addresses, IPs, financial data (account numbers, card details, CVV), automotive identifiers (VINs), and government IDs into JWT payloads. When tokens leak or are logged, that data becomes exposed.

    Why: Convenience, lack of data-minimization, poor logging practices, and confusion between base64 encoding and encryption.

    Fix: Remove PII from tokens — store only minimal identifiers (e.g., token ID) and fetch sensitive data server-side. Scrub logs and telemetry of token payloads.

  1. JSON Web Token (JWT) with long TTLs — 21%

    Long-lived tokens increase the window for replay or theft.

    Why: UX tradeoffs, use of single master tokens instead of session tokens, missing refresh patterns, and no risk-tiered TTLs.

    Fix: Shorten access token lifetimes, introduce refresh tokens, and apply shorter TTLs for high-risk scopes.

  1. Weak signing algorithms — 19%

    Use of weak or misconfigured algorithms (e.g., unsafe defaults like HS256 without strict verification) leaves tokens vulnerable to forgery or downgrade attacks.

    Why: Legacy libraries, unchanged defaults, no enforcement of allowed algorithms, and lack of key rotation.

    Fix: Enforce strong algorithms (RS256/ES256), reject alg: none or unexpected alg fields, and rotate keys regularly.

  2. Basic Auth with raw credentials — 9%

    Some endpoints still accept Basic Auth, exposing credentials to intercept or log leaks.

    Why: Legacy endpoints, backward compatibility needs, or quick integrations that were never refactored.

    Fix: Migrate to modern auth (OAuth2, mTLS) and remove Basic Auth endpoints or protect them behind VPNs/gateways during migration.

  3. Apps accessible after tokens expire — 5.0%

    Tokens not being validated or server-side invalidation missing allows access even after expiry.

    Why: Client-only checks, missing server exp/nbf validation, stale caches/CDNs, clock skew, or misconfigured gateways.

    Fix: Enforce server-side exp (Expiration Time – indicates exact time after which the token is no longer valid) /nbf (Not Before – specifies the time before which the token must not be accepted for processing) checks, propagate invalidation to caches/CDNs, and implement logout/session revocation flows.

Why these problems persist

APIs evolve quickly—new endpoints, integrations, and releases are frequent. Teams prioritize feature velocity, sometimes at the expense of auth hygiene. Misunderstandings about JWT semantics (e.g., base64 ≠ encryption), legacy compatibility, and the lure of “simpler” UX all contribute to the drift.

One-time audits and periodic pen tests can’t catch continual configuration drift or newly deployed endpoints. That’s where continuous assessment matters.

Continuous risk assessment: What it delivers

Continuous API risk assessment provides:

  • Real-time visibility into every new API, endpoint, and token usage.
  • Early detection of misconfigurations before they’re exploited.
  • Automated prevention via policy enforcement and blocking of risky deployments.
  • Lower overhead through automated scans that let teams focus on remediation.

Imperva API Security provides ongoing visibility, preventive controls, and detailed reporting so teams can track remediation and compliance over time. Customers can also generate periodic API risk reports from the console for governance and executive updates.

Quick playbook—immediate priorities

  1. Today: scan for tokens carrying PII; stop logging token payloads.
  2. 48–72 hours: shorten TTLs for high-risk tokens; enable refresh token flows.
  3. 1–2 weeks: enforce allowed signing algorithms and start key rotation.
  4. 1 month: remove Basic Auth or protect legacy endpoints; implement server-side token invalidation and cache purge procedures.

Conclusion & next steps

Authentication misconfigurations are common but fixable. Most high-impact improvements (removing sensitive claims, shortening TTLs, enforcing algorithms) are straightforward and deliver immediate risk reduction.

If you’d like, our team can run a targeted audit of your token usage, produce a prioritized remediation plan, and provide SE-led support to close the top findings quickly. Reach out to schedule a risk review and harden your auth layer before attackers exploit it.

The post Imperva API Security: Authentication Risk Report—Key Findings & Fixes appeared first on Blog.

Related Posts