Common Backend Vulnerabilities
Authentication & Authorization
Spring Security JWT authentication
When we build applications, we naturally focus on making things work. We ask ourselves: "How do I implement this feature?" or "How do I make this faster?" This is the builder's mindset, and it's essential for creating software. But there's another equally important perspective: the attacker's mindset. Instead of asking, "How do I build this?" we ask, "How could this be broken?" This shift in thinking is what we refer to as the Security Mindset.
IBM Technology has created an informative video about basic cyber security principles
https://www.youtube.com/watch?v=jq_LZ1RFPfU
There's a common misconception that security is someone else's job—perhaps a dedicated security team or a specialist who reviews the code later. This thinking is dangerous for several reasons:
“The reality: Every line of code you write is a potential attack surface. Security isn't a feature you add—it's a quality you build in from the start.”
To defend your application, you need to understand how attackers think. This doesn't mean you need to become a hacker, but you should develop the habit of questioning your own work. How do I process this input?
| Builder's Question | Attacker's Question |
|---|---|
| How do I authenticate users? | How can I bypass authentication? |
| How do I store user data? | How can I access other users' data? |
| How do I process this input? | What happens if I send unexpected input? |
| How do I handle errors? | What information do errors reveal? |
| How do I limit access to admins? | How can I escalate my privileges? |
When building features, we often imagine the "happy path" a well-meaning user is doing exactly what we expect. Attackers don't follow the happy path. They:
Consider a simple endpoint that retrieves a user's profile:
@GetMapping("/api/users/{id}")
public User getUser(@PathVariable Long id) {
return userRepository.findById(id);
}
Builder's perspective: This works! It returns the user with the given ID.
Attacker's perspective:
Never trust data coming from outside your application. This includes:
Ask yourself: "What's the worst thing someone could send here?”
Give users, processes, and systems only the minimum permissions they need to function. Ask yourself: "Does this user/process really need this level of access?"
Don't rely on a single security measure. Layer your defenses so that if one fails, others still protect you.
Ask yourself: "If this security control fails, what else would stop an attacker?"
When something goes wrong, your application should fail in a way that doesn't expose sensitive information or leave the system in an insecure state. Ask yourself: "What happens when this fails? What does the user see? What gets logged?"
Complex systems are harder to secure. The more code you have, the more potential vulnerabilities exist. Ask yourself: "Is there a simpler way to do this?"
<aside> 💡
In the next section, we'll learn how to systematically identify threats in your applications using a simplified threat modeling approach.
</aside>
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.