Common Backend Vulnerabilities
Authentication & Authorization
<aside> 🚧
This page is currently under construction. Please check back later.
</aside>
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.
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:
You know your code best: You understand the logic, the edge cases, and the assumptions you made while building it. A security specialist reviewing it later won't have this context.
Security added later is expensive: Fixing a vulnerability in production can cost 10-100x more than fixing it during development. It's not just about money, it's about user trust, data breaches, and your reputation.
Attackers don't wait: The moment your application goes live, it's a target. Automated bots scan the internet constantly, looking for common vulnerabilities. They don't care if you planned to "add security later."
“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?"
In the next section, we'll learn how to systematically identify threats in your applications using a simplified threat modeling approach.
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.