Common Attacks

Attacks and Defences

Attack	What happens	Defence (Spring / you)
Brute force	trying thousands of passwords for one account	slow hashing, account lockout, rate limiting, CAPTCHA
Credential stuffing	reusing email/password pairs leaked from other sites	MFA, breached-password checks, rate limiting
SQL injection	input like `' OR 1=1 --` changes your query	JPA / prepared statements, never concatenate SQL
XSS	attacker script runs in other users' browsers	escape output (Thymeleaf/React do), Content-Security-Policy, HttpOnly cookies
CSRF	forged request rides on your cookie	CSRF token (on by default), SameSite cookies
Session fixation	attacker plants a known session id before you log in	Spring changes the session id at login (default)
Clickjacking	your page loaded invisibly in an iframe	`X-Frame-Options: DENY` (default header)
Sniffing / MITM	reading traffic on the network	HTTPS everywhere, HSTS
Timing attack	measuring how long a comparison takes	constant-time compare (`MessageDigest.isEqual`, encoders do this)

SQL Injection in One Example

Example

Concatenating user input into SQL lets the input change the query itself. A parameterised query treats it as plain data:

public class Main {
    public static void main(String[] args) {
        String email = "x' OR '1'='1";

        String unsafe = "SELECT * FROM users WHERE email = '" + email + "'";
        System.out.println("Concatenated: " + unsafe);
        System.out.println("  -> matches EVERY user");

        String safe = "SELECT * FROM users WHERE email = ?";
        System.out.println("Prepared:     " + safe + "   [param 1 = " + email + "]");
        System.out.println("  -> looks for a user whose email is literally that text");
    }
}

Output

Concatenated: SELECT * FROM users WHERE email = 'x' OR '1'='1'
  -> matches EVERY user
Prepared:     SELECT * FROM users WHERE email = ?   [param 1 = x' OR '1'='1]
  -> looks for a user whose email is literally that text

Note: Spring Data JPA derived queries and @Query with parameters are always parameterised. Danger appears only when you build SQL/JPQL strings by hand.

Default Security Headers

Example

Spring Security adds protective headers to every response without any configuration:

curl -I -u asha:asha123 https://shopease.in/api/cart

Example output

HTTP/1.1 200
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY