Spring Security

Diese Seite bleibt auch ohne JavaScript lesbar. Suche und Buttons sind Zusatzkomfort.

Spring Security im Enterprise-System

Authentication, Authorization, Filter Chain, OAuth2/JWT und methodische Policies.

Spring Security: Filter Chain vor der Fachlogik RequestToken AuthNIdentität AuthZRechte CSRF/CORSSchutz Controllernur wenn erlaubt Enterprise-Regel: Security ist kein Controller-if, sondern ein Querschnitt mit klaren Policies.
1. Security als Filter Chain und Policy-Modell

Spring Security sitzt vor Controller und Service. Es prüft Identität, Berechtigungen, Session-/Token-Mechanik, CSRF/CORS und weitere Schutzmaßnahmen. Der wichtigste Denkfehler ist, Security als verstreute if-Abfragen im Controller zu implementieren.

Enterprise-Systeme brauchen Rollen, Scopes, Mandantenkontext, technische Clients, Benutzeraktionen und Auditierbarkeit. Das sollte als Security-Modell dokumentiert und getestet werden.

SecurityFilterChain mit JWT Resource Server
@Configuration
@EnableMethodSecurity
class SecurityConfig {
    @Bean
    SecurityFilterChain api(HttpSecurity http) throws Exception {
        return http
            .csrf(csrf -> csrf.disable())
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/actuator/health", "/actuator/info").permitAll()
                .requestMatchers(HttpMethod.POST, "/api/orders").hasAuthority("SCOPE_orders.write")
                .requestMatchers(HttpMethod.GET, "/api/orders/**").hasAuthority("SCOPE_orders.read")
                .anyRequest().authenticated())
            .oauth2ResourceServer(oauth -> oauth.jwt(Customizer.withDefaults()))
            .build();
    }
}
2. Method Security für fachliche Regeln

URL-Regeln beantworten: darf dieser Request grundsätzlich diese Route aufrufen? Method Security beantwortet zusätzlich: darf dieser Benutzer diese fachliche Aktion auf diesem Objekt ausführen? Für Mandantenfähigkeit oder Besitzregeln ist Method Security oft sauberer.

Policy Bean mit @PreAuthorize
@Service
class OrderQueryService {
    private final OrderRepository orders;

    @PreAuthorize("@orderPolicy.canRead(authentication, #id)")
    public OrderDetails findDetails(UUID id) {
        return orders.findDetails(id)
                .orElseThrow(() -> new NotFoundException("order", id));
    }
}

@Component
class OrderPolicy {
    boolean canRead(Authentication authentication, UUID orderId) {
        return authentication.getAuthorities().stream()
                .anyMatch(a -> a.getAuthority().equals("SCOPE_orders.read"));
    }
}
3. Typische Fehler

Häufige Schwachstellen sind zu breite Wildcard-Regeln, ungeschützte Actuator-Endpunkte, fehlende Tests für 401/403, nicht validierte JWT-Claims, unklare CORS-Regeln und Security-Logik, die nur im Frontend existiert.

Security Test für 403
@WebMvcTest(OrderController.class)
class OrderControllerSecurityTest {
    @Autowired MockMvc mvc;

    @Test
    void postOrderRequiresWriteScope() throws Exception {
        mvc.perform(post("/api/orders").with(jwt().authorities(new SimpleGrantedAuthority("SCOPE_orders.read"))))
           .andExpect(status().isForbidden());
    }
}

Enterprise-Prüffragen

  • Actuator-Endpunkte bewusst abgesichert?
  • 401 und 403 getestet?
  • Scopes/Rollen fachlich dokumentiert?
  • Method Security für Objektregeln genutzt?