Week 10

Security Mindset

Threat Modeling Basics

Common Backend Vulnerabilities

Handling Sensitive Data

Hashing vs. Encryption

How to Store Passwords

Authentication & Authorization

Spring Security

Spring Security JWT authentication

Practice

Assignment

• Teachers

Backend Track

Content

Let’s get practical

Exercise 1 - Improve your project

Add authentication system to your week 7 project:

• Create register and login endpoints
• Handle passwords securely
• Integrate Spring Boot Security
• Implement either a JWT authentication or session authentication
• Test your application for security.

Exercise 2 — Crack a bcrypt hash

Type: coding (Java)

You've been handed a leaked password hash. The company had a weak password policy, so every password follows the format HackYourFuture followed by a 4-digit number (HackYourFuture0000 to HackYourFuture9999). The stolen hash:

$2b$10$qeQy/F75FZ06fWPnREh.pelDL.QwCQIbVPRP4qq9aqJouzMYNfK.2

Write a small Java program that loops through all 10,000 candidates and uses BCryptPasswordEncoder.matches(candidate, hash) to find the original password. Print the password once you find it, and print how long the search took.

Reflect (as comments in your code):

• Roughly how long did each matches() call take, and why is it so slow compared to a normal hash?
• If the password format were unknown (any length, any characters), would this attack still be realistic?
• What would happen to your attack if the hash used a higher bcrypt cost factor?

Hint: it will take a few minutes to run — that slowness is the whole point of bcrypt.

Exercise 3 — Tamper with and forge a JWT

Type: hands-on

Here is a token issued by an API:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQyIiwidXNlcm5hbWUiOiJzYW0iLCJyb2xlIjoiVVNFUiIsImV4cCI6NDEwMjQ0NDgwMH0.6inBRrghilltJq-MGw5uCbG5YBSfSZp7rAAZgPs4Xh4

Part A — read it: Paste the token into jwt.io (or Base64Url-decode the first two parts yourself). What is the user's role? What does this prove about storing sensitive data in a payload?

Part B — tamper (and fail): Change the role claim from USER to ADMIN, keep the original signature, and try to verify the token against the secret hyf-super-secret-key-2024. It should be rejected — explain in one sentence why.

Part C — forge (with the secret): Now that you have the secret, generate a brand-new valid token where role is ADMIN. Verify it passes. Write one sentence on why knowing the secret changes everything, and where that secret must never end up.

Use any JWT library (jjwt or java-jwt), or jwt.io's editor for a quick version.

Exercise 4 — Exploit and fix SQL Injection

Type: coding (Java)

Start with this deliberately vulnerable login lookup:

String sql = "SELECT * FROM users WHERE username = '" + username + "'";

1. Set up a tiny users table with one or two rows.
2. Log in as a normal user to confirm it works.
3. Break it: log in without knowing any password by passing ' OR '1'='1' -- as the username.
4. Fix it: rewrite the query using JdbcClient with a named parameter, and confirm the same input now fails safely.

Deliverable: the vulnerable version, the exploit input, and the fixed version — plus one sentence on why the parameterized version is immune.

Exercise 5 — Find and fix an IDOR

Type: coding (Java)

This endpoint returns any order to any logged-in user:

@GetMapping("/api/orders/{id}")
public Order getOrder(@PathVariable Long id) {
    return orderRepository.findById(id)
            .orElseThrow(() -> new NotFoundException("Order not found"));
}

1. Seed two users, each with one order (order 1 → Alice, order 2 → Bob).
2. Logged in as Alice, request GET /api/orders/2 and confirm you can read Bob's order — that's the IDOR.
3. Fix it by adding an ownership check so a user can only access their own orders, returning 403 Forbidden otherwise.
4. Re-run the attack and confirm Alice is now blocked.

Reflect: why is "being logged in" not the same as "being allowed"? Why are UUIDs a helpful second layer but not a real fix?

Exercise 6 — Threat-model a feature (no code)

Type: written

Pick one feature from an app you've built (e.g. "user uploads a profile picture" or "reset password by email"). Put on your attacker hat and write down:

• Assets: what is worth protecting here? (data, accounts, money, reputation)
• Entry points: where does untrusted input enter the feature?
• Threats: 3–5 concrete ways someone could abuse it. Map each to something from this week — injection, broken access control, XSS, information disclosure, missing rate limiting.
• Mitigations: for each threat, one sentence on how you would defend against it.

Deliverable: a half-page threat model. There is no single right answer — the goal is to practise thinking about what can go wrong before writing code.

The HackYourFuture curriculum is licensed under CC BY-NC-SA 4.0 *https://hackyourfuture.net/*

Built with ❤️ by the HackYourFuture community · Thank you, contributors

Found a mistake or have a suggestion? Let us know in the feedback form.