From e89dd5dc3ce08220489e7c8dea5d6939141aaac6 Mon Sep 17 00:00:00 2001 From: Marcel Date: Sun, 15 Mar 2026 12:27:50 +0100 Subject: [PATCH] docs: document why CSRF is intentionally disabled in SecurityConfig The previous comment implied CSRF was disabled as a temporary dev convenience. Replaced it with an explanation of why it is safe with the current Authorization-header-based auth scheme, and added a clear note on when it must be re-enabled. Co-Authored-By: Claude Sonnet 4.6 --- .../org/raddatz/familienarchiv/config/SecurityConfig.java | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/backend/src/main/java/org/raddatz/familienarchiv/config/SecurityConfig.java b/backend/src/main/java/org/raddatz/familienarchiv/config/SecurityConfig.java index 54609315..65608e11 100644 --- a/backend/src/main/java/org/raddatz/familienarchiv/config/SecurityConfig.java +++ b/backend/src/main/java/org/raddatz/familienarchiv/config/SecurityConfig.java @@ -35,7 +35,12 @@ public class SecurityConfig { @Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http - // CSRF für Entwicklung aus, damit wir Postman/REST Client nutzen können + // CSRF is intentionally disabled: every request from the SvelteKit frontend + // carries an explicit Authorization header (Basic Auth token injected by + // hooks.server.ts). Browsers block cross-origin requests from setting custom + // headers, so cross-site request forgery via a third-party page is not + // possible with this auth scheme. If the auth model ever changes to + // cookie-based sessions, CSRF protection must be re-enabled. .csrf(csrf -> csrf.disable()) .authorizeHttpRequests(auth -> auth