Credential Stuffing in Spring Boot with Basic Auth

Credential stuffing is an automated attack in which lists of breached username and password pairs are systematically submitted to an authentication endpoint to find valid accounts. When Basic Auth is used in a Spring Boot application, the browser or client sends an Authorization header on every request after the initial challenge, which can make it easier for an automated attacker to reuse stolen credentials across multiple sessions without triggering account lockout mechanisms if they are weak or absent.

Spring Boot applications that rely solely on Basic Auth over HTTP (or without additional protections) expose several risk dimensions. First, because the credentials are sent with each request, intercepted tokens or weakly protected storage on the client side can lead to replay. Second, if the backend does not enforce strong rate limiting or anomaly detection per user, attackers can iterate through many credentials quickly. Third, Basic Auth does not inherently bind a session to additional factors, so once credentials are valid, the attacker gains the same access as the legitimate user. The lack of multi-factor authentication, weak password policies, and reuse of credentials across services amplify the impact. In an unauthenticated scan, middleBrick tests for exposed authentication surfaces, and one of the checks it runs under Authentication and Rate Limiting can surface whether Basic Auth endpoints allow high request rates without throttling, making credential stuffing feasible.

Attackers often combine credential stuffing with other techniques such as credential harvesting from public breaches, automated tooling that parses 401 responses to refine guesses, and evasion through rotating IPs or user-agents. In a black-box scan, middleware that does not enforce per-user rate limits or does not lock or degrade after repeated failures can show a weak authentication posture. Developers should treat Basic Auth as transport-level convenience and not as a robust sole authentication mechanism for high-risk endpoints.

To reduce the risk of credential stuffing when using Basic Auth in Spring Boot, combine transport security, rate limiting, and strong authentication practices. Below are concrete remediation steps with code examples.

• Enforce HTTPS to protect credentials in transit. Configure your embedded server to require SSL and redirect HTTP to HTTPS.

# application.properties
server.port=8443
server.ssl.key-store=classpath:keystore.p12
server.ssl.key-store-password=changeit
server.ssl.key-store-type=PKCS12
server.ssl.key-alias=tomcat

• Add per-user rate limiting using a token bucket algorithm to prevent rapid credential trials. Spring Cloud Gateway or a Servlet Filter can be used; here is a simple filter approach.

import jakarta.servlet.FilterChain;
import jakarta.servlet.ServletException;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import org.springframework.stereotype.Component;
import org.springframework.web.filter.OncePerRequestFilter;
import java.io.IOException;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.TimeUnit;

@Component
public class RateLimitFilter extends OncePerRequestFilter {

    private final ConcurrentHashMap buckets = new ConcurrentHashMap<>();
    private static final long WINDOW_MS = 60_000; // 1 minute
    private static final int MAX_REQUESTS = 30;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
            throws ServletException, IOException {
        String key = request.getRemoteAddr() + "-" + request.getHeader("Authorization");
        RateBucket bucket = buckets.computeIfAbsent(key, k -> new RateBucket());
        if (!bucket.tryConsume()) {
            response.setStatus(HttpServletResponse.SC_TOO_MANY_REQUESTS);
            return;
        }
        filterChain.doFilter(request, response);
    }

    private static class RateBucket {
        private int tokens = MAX_REQUESTS;
        private long lastRefill = System.currentTimeMillis();

        synchronized boolean tryConsume() {
            refill();
            if (tokens > 0) {
                tokens--;
                return true;
            }
            return false;
        }

        private void refill() {
            long now = System.currentTimeMillis();
            long elapsed = now - lastRefill;
            if (elapsed >= WINDOW_MS) {
                tokens = MAX_REQUESTS;
                lastRefill = now;
            }
        }
    }
}

• Use Spring Security to require secure transport and apply authentication rules. The following example configures HTTP Basic with custom entry points and requires secure channels.

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .requiresChannel(channel -> channel
                .anyRequest().requiresSecure()
            )
            .httpBasic(httpBasic -> httpBasic
                .authenticationEntryPoint(new CustomBasicAuthenticationEntryPoint())
            )
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/public/**").permitAll()
                .anyRequest().authenticated()
            );
        return http.build();
    }
}

• Implement adaptive responses and account protection. After repeated failures for a given user, introduce temporary delays or require re-authentication. Combine with additional signals such as user-agent or IP reputation where feasible.

• Encourage or enforce stronger passwords and consider multi-factor authentication for privileged accounts. Basic Auth should be treated as one factor in a broader strategy.

By layering HTTPS, per-user rate limiting, secure transport requirements, and adaptive protections, you reduce the effectiveness of credential stuffing against Basic Auth endpoints in Spring Boot while maintaining compatibility with existing clients.