Medium SeveritySecurityAuthentication

The No-Password Null Pointer Crash

1.The Symptom (The Chaos)

A user attempts to access a protected API route using a valid social token, but the backend unexpectedly crashes with an unhandled HTTP 500 error containing a NullPointerException inside the Spring Security filter chain.

2.The Trigger Condition

A user registers or logs into the application using a third-party provider (like Google or GitHub OAuth2), creating a local database profile where the password credential column remains uninitialized or null.

3.The Catch (Why it broke)

We mapped the raw database user entity directly into Spring Security's UserDetails contract, forgetting that the framework internally evaluates the password string, causing the entire request filter pipeline to choke on uninitialized null fields.

4.Architectural Trade-offs

Using a dedicated framework placeholder string keeps the filter pipeline perfectly stable without needing to write a fully custom, multi-class UserDetails authentication provider, but requires strict validation downstream to prevent traditional login forms from trying to match against the placeholder.

security/JwtAuthenticationFilter.java

[Naive UserDetails Mapping]

// VULNERABLE: Naïvely passing the database entity password property directly.
// For social profiles (Google/GitHub), user.getPassword() returns null, causing 
// Spring's User details validator to throw an unhandled NullPointerException.
private UsernamePasswordAuthenticationToken createAuthToken(User user, HttpServletRequest request) {
    org.springframework.security.core.userdetails.User principal =
            new org.springframework.security.core.userdetails.User(user.getEmail(), user.getPassword(), List.of());

    UsernamePasswordAuthenticationToken authToken =
            new UsernamePasswordAuthenticationToken(principal, null, List.of());

    authToken.setDetails(new WebAuthenticationDetailsSource().buildDetails(request));
    return authToken;
}