Why AI tools produce this: AI coding tools produce this regularly, typically when prompted for a shortcut or a quick fix.
Why this matters
WebSecurity.ignoring() removes the matched paths from the Spring Security filter chain entirely, so they get no authentication, authorization, CSRF, or header protection at all. Passing the /** wildcard excludes every request, leaving the whole application unprotected (CWE-862). This is a common AI-generated shortcut to silence security errors during development that then ships to production.
Never ignoring() a broad wildcard. Limit it to genuinely static, non-sensitive assets, e.g. web.ignoring().requestMatchers("/css/**", "/js/**"), or better, handle authorization inside the filter chain with permitAll() on scoped paths so the security headers still apply.
import org.springframework.security.config.annotation.web.builders.WebSecurity;import org.springframework.security.config.annotation.web.configuration.WebSecurityCustomizer;class SecurityConfig { // ok: auth.java.web.security-ignoring-all -- scoped static assets, not the "/**" wildcard WebSecurityCustomizer webSecurityCustomizer() { return (web) -> web.ignoring().requestMatchers("/css/**", "/js/**"); } // ok: auth.java.web.security-ignoring-all -- scoped static assets in the legacy API void legacyConfigure(WebSecurity web) { web.ignoring().antMatchers("/images/**", "/webjars/**"); }}
Suppressing this rule
If a finding is a genuine false positive, scope the suppression to the exact line and leave a reason, never disable the rule project-wide. Disable directives are line-scoped by design.