marcel/familienarchiv
1
0
Fork 0
Code Issues 106 Pull Requests 3 Actions Packages Projects Releases Wiki Activity

docs(auth): document XFF trust-the-proxy assumption on resolveClientIp

Browse Source 
Pure-comment change: spell out that resolveClientIp's leftmost-X-Forwarded-For
strategy is safe only because Caddy strips client-supplied XFF before
forwarding. Future readers swapping the ingress have a tripwire. Addresses PR
#612 / Nora concern (XFF trust documentation).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Marcel
2026-05-17 22:41:39 +02:00
parent c7782d554f
commit 20fe83d889
1 changed files with 9 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
backend/src/main/java/org/raddatz/familienarchiv/auth/AuthSessionController.java
View File

@@ -78,6 +78,15 @@ public class AuthSessionController {
return ResponseEntity.noContent().build(); return ResponseEntity.noContent().build();
} }
/**
* Resolves the client IP for audit-log purposes.
*
* <p>Trust model: the leftmost {@code X-Forwarded-For} value is taken at face value.
* This is correct <em>only</em> if the ingress (Caddy in production) strips any
* client-supplied XFF before forwarding — otherwise an attacker can pin audit-log
* IPs to whatever they want. Verify the reverse-proxy config before exposing this
* service behind a different ingress.
*/
private static String resolveClientIp(HttpServletRequest request) { private static String resolveClientIp(HttpServletRequest request) {
String forwarded = request.getHeader("X-Forwarded-For"); String forwarded = request.getHeader("X-Forwarded-For");
if (forwarded != null && !forwarded.isBlank()) { if (forwarded != null && !forwarded.isBlank()) {