Credential Stuffing in Spring Boot with Bearer Tokens

Credential stuffing is an automated attack where valid credentials obtained from one breach are systematically tried against many services. When a Spring Boot API relies solely on Bearer tokens for authentication without additional protections, it can become an attractive target. The risk is not that Bearer tokens are inherently weak, but that the API may accept tokens issued from other compromised services, or that token issuance endpoints or token validation logic may be abused as part of a broader credential stuffing workflow.

Spring Boot applications often integrate with identity providers or custom authentication filters that validate Bearer tokens. If these integrations do not enforce strict token binding to the authenticated user context and do not validate token origin, an attacker can automate requests with stolen or guessed tokens. For example, an attacker might use a list of email and password pairs to obtain tokens via a compromised identity provider, then replay those tokens against your Spring Boot endpoints that rely on token introspection or JWT validation without rate limiting or multi-factor checks.

Another specific exposure arises when token issuance endpoints lack proper controls. If an endpoint that exchanges credentials for Bearer tokens does not implement account lockout, captcha, or rate limiting, automated credential stuffing can directly target that endpoint. Even when tokens are validated using Spring Security’s BearerTokenAuthenticationFilter, the application may still authorize requests if the token is valid and not revoked, regardless of whether the login preceding token issuance involved suspicious patterns. This means the attack surface includes both token acquisition (credential stuffing) and token usage (API abuse).

Additionally, if your API exposes user enumeration via timing differences or error messages during token validation, attackers can refine their stuffing campaigns. Spring Boot applications that return distinct responses for invalid tokens versus missing tokens can inadvertently assist attackers. The framework’s default behavior may not differentiate these cases strongly enough, especially if custom filters inadvertently leak information through logs or HTTP status codes. Lack of request fingerprinting, device or IP correlation, and weak token entropy further enable successful token replay across accounts.

Consider an OpenAPI 3.0 definition where the security scheme specifies a Bearer token:

openapi: 3.0.3
info:
  title: Example API
  version: 1.0.0
paths:
  /api/resource:
    get:
      summary: Get protected resource
      security:
        - bearerAuth: []
      responses:
        '200':
          description: OK
components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT

An attacker can use this specification to craft valid authenticated requests once a token is obtained through credential stuffing. Without runtime protections like rate limiting tied to user identity or token origin, the API will process these requests as legitimate.

Remediation focuses on token binding, strict validation, and reducing the effectiveness of automated stuffing campaigns. You should ensure that each Bearer token is strongly tied to the user’s identity and context, and that token validation includes checks that make token reuse across accounts more difficult.

First, customize the authentication filter chain to include token context validation. Below is a concrete Spring Boot Java configuration that adds a custom filter after Bearer token extraction to verify additional claims (such as a session or device identifier) before authentication proceeds:

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf().disable()
            .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            .and()
            .addFilterBefore(new BearerTokenContextFilter(), UsernamePasswordAuthenticationFilter.class)
            .authorizeHttpRequests(authz -> authz
                .requestMatchers("/public/**").permitAll()
                .anyRequest().authenticated()
            )
            .oauth2ResourceServer(OAuth2ResourceServerConfigurer::jwt);
        return http.build();
    }

    public static class BearerTokenContextFilter extends OncePerRequestFilter {
        @Override
        protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
                throws ServletException, IOException {
            String token = extractToken(request);
            if (token != null) {
                // Example: validate custom claim to mitigate token replay across contexts
                Jwt jwt = Jwt.withTokenValue(token)
                    .headers(h -> h)
                    .claims(c -> {
                        // Intentionally left as example; real validation occurs via JwtDecoder
                    })
                    .build();
                // Additional context checks could be performed here before proceeding
            }
            filterChain.doFilter(request, response);
        }

        private String extractToken(HttpServletRequest request) {
            String bearer = request.getHeader("Authorization");
            if (StringUtils.hasText(bearer) && bearer.startsWith("Bearer ")) {
                return bearer.substring(7);
            }
            return null;
        }
    }
}

Second, enforce token binding to the client or device by validating custom JWT claims and tying token usage to a fingerprint derived from request attributes. Below is a service-level check that you can integrate into your authorization logic:

@Service
public class TokenValidationService {

    public void validateTokenContext(Jwt jwt, HttpServletRequest request) {
        String clientFingerprint = request.getHeader("X-Client-Fingerprint");
        String tokenFingerprint = jwt.getClaim("device_fingerprint");
        if (!StringUtils.hasText(clientFingerprint) || !clientFingerprint.equals(tokenFingerprint)) {
            throw new BadCredentialsException("Token context mismatch");
        }
        // Optionally check token reuse by verifying jti against a short-lived cache
    }
}

Third, protect the token issuance endpoint with rate limiting and strong credential validation. Even though the focus is Bearer tokens, the path that produces them must resist automated abuse:

@PostMapping("/oauth/token")
public ResponseEntity issueToken(@RequestBody LoginRequest login, HttpServletRequest request) {
    // Apply rate limiting per IP or device fingerprint before processing credentials
    if (!rateLimiter.attempt(request.getRemoteAddr())) {
        return ResponseEntity.status(HttpStatus.TOO_MANY_REQUESTS).body(Map.of("error", "rate_limit_exceeded"));
    }
    // Validate credentials against user store
    // On success, issue a JWT with device fingerprint claim
    String token = Jwts.builder()
        .setSubject(login.getUsername())
        .claim("device_fingerprint", request.getHeader("X-Client-Fingerprint"))
        .signWith(SignatureAlgorithm.HS256, "secret")
        .compact();
    return ResponseEntity.ok(Map.of("access_token", token, "token_type", "Bearer"));
}

Finally, integrate these practices with your API specification so that security expectations are clear. Using middleBrick’s OpenAPI/Swagger analysis, you can ensure that your spec reflects required custom claims and that runtime findings align with defined security schemes. This combination of framework hardening, token context checks, and endpoint protection reduces the effectiveness of credential stuffing against Bearer token-based Spring Boot APIs.