Medium SeverityAuthenticationConcurrencySecurity

The Magic Link Race Condition

1.The Symptom (The Chaos)

Magic links fail instantly due to background email security scans or cross-device browser mismatches.

2.The Trigger Condition

A user clicks a magic link in their email client, triggering an HTTP GET request to the backend verification endpoint.

3.The Catch (Why it broke)

We assumed standard read-and-save validation and strict fingerprint matching would secure magic links, failing to realize email scanners pre-fetch URLs concurrently and users routinely open email links on different devices.

4.Architectural Trade-offs

To resolve this, we replace hard device blocking with temporary restricted sessions and use atomic SQL updates for single-use token validation—trading strict device immutability for reliable cross-device UX.

service/AuthService.java

[Non-Atomic Read-And-Save Verification]

// VULNERABLE: Read-and-save pattern allows concurrent email scanners 
// or double-clicks to pass the 'isConsumed' check before 'save()' executes.
User user = userRepository.findByEmail(email).orElseThrow();
if (user.isMagicTokenConsumed()) {
    throw new AuthException("Token already used.");
}

// Strict fingerprint check causes hard lockout if opened cross-device
if (!user.getFingerprint().equals(clientFingerprint)) {
    throw new FingerprintMismatchException("Cross-device login forbidden.");
}

user.setMagicTokenConsumed(true);
userRepository.save(user); // <--- Race window open until DB commit finishes!