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

Introduction

In the previous section, we discussed developing a security mindset—learning to think like an attacker. But how do we apply this systematically? How do we ensure we're not missing critical threats? This is where threat modeling comes in. Threat modeling is a structured approach to identifying security threats, understanding their potential impact, and deciding how to address them. Think of it as a security brainstorming session with a framework to guide your thinking.

Watch: Fundamentals of CIA (Confidentiality, Integrity and Availability)

Before jumping into Threat Modeling, watch the following video about the most fundamental concept in cybersecurity — CIA.

https://www.youtube.com/watch?v=EqNe55IzjAw

What is Threat Modeling?

At its core, threat modeling answers four key questions:

1. What are we building? → Understand the system
2. What can go wrong? → Identify threats
3. What are we going to do about it? → Plan mitigations
4. Did we do a good job? → Validate and iterate “this can be a bit complicated to this level.”

<aside> ⚠️

You don't need to be a security expert to do threat modeling. If you can describe how your system works and ask "what if?" questions, you can threat model.

</aside>

Why Threat Model?

Without Threat Modeling Developers often discover security issues through:

• Penetration testing - Hire someone to try to hack your system and report the issues (expensive, late in the process).
• Security incidents in production (costly, damages trust)
• Random code reviews (inconsistent, depends on reviewer knowledge)

With Threat Modeling, you proactively identify threats before writing code or during design:

• Cheaper to fix issues during design than in production
• Creates shared understanding among team members
• Document security decisions for future reference
• Helps prioritize security work based on risk

<aside> 💡

Key insight: Threat modeling shifts security from reactive "fix this vulnerability" to proactive "prevent this class of vulnerabilities".

</aside>

The STRIDE Framework

Watch: A quick overview of STRIDE

https://www.youtube.com/watch?v=J3V4x5QtFus

STRIDE is a mnemonic developed by Microsoft to help categorize threats. Each letter represents a different type of threat:

STRIDE in Practice

Let's see how STRIDE applies to a simple login feature:

A Simple Threat Modeling Process

Here's a practical 5-step process you can apply to any feature or system:

Step 1: Draw Your System

Create a simple diagram showing:

• Components (web app, API, database, external services)
• Data flows (how information moves between components)
• Trust boundaries (where privilege levels change)

Step 2: Identify Assets

What are you protecting? List the valuable things in your system:

Step 3: Apply STRIDE to Each Component“

For each component and data flow, systematically ask STRIDE questions.

Step 4: Prioritise Threats

Not all threats are equal. Use a simple risk matrix to prioritize:

Factors affecting likelihood:

• Is the attack easy to perform?
• Is there existing exploit code?
• Is the component exposed to the internet?

Factors affecting impact:

• What data could be compromised?
• Could this affect all users or just one?
• What's the regulatory/legal consequence?

Step 5: Plan Mitigations

For each prioritized threat, decide on a response:

| --- | --- | --- |

Threat Modeling Practical Example

Let's walk through a complete example. Consider this endpoint for updating user profiles:

@PutMapping("/api/users/{userId}/profile")
@PreAuthorize("isAuthenticated()")
public UserProfile updateProfile(
    @PathVariable Long userId,
    @RequestBody ProfileUpdateRequest request
) {
    return userService.updateProfile(userId, request);
}

STRIDE Analysis

| --- | --- | --- | --- |

Resulting Secure Implementation

@PutMapping("/api/users/{userId}/profile")
@PreAuthorize("isAuthenticated()")
public ResponseEntity<ProfileResponse> updateProfile(
    @PathVariable Long userId,
    @Valid @RequestBody ProfileUpdateRequest request,
    @AuthenticationPrincipal UserDetails currentUser
) {
    // TAMPERING: Verify user can only update their own profile
    if (!currentUser.getId().equals(userId)) {
        throw new AccessDeniedException("Cannot update another user's profile");
    }
    
    // TAMPERING: Use DTO to only accepts allowed fields (name, bio, avatar)
    UserProfile updated = userService.updateProfile(userId, request);
    
    // REPUDIATION: Audit log the change
    auditService.log("PROFILE_UPDATE", userId, request);
    
    // INFO DISCLOSURE: Return only safe fields via response DTO
    return ResponseEntity.ok(ProfileResponse.from(updated));
}