When I started learning cybersecurity seriously, one thing became very clear very quickly: reading about vulnerabilities is not the same as understanding them.

You can memorize definitions of SQL Injection, XSS, or Broken Authentication — but until you see how a small mistake in an application can be exploited, security remains abstract. That realization pushed me to focus on hands-on learning, and that's how I started working through the OWASP Top 10 using PortSwigger Web Security Academy.

This post documents why I chose this path, what I learned, and how it's shaping the way I think about application security as an entry-level candidate.

Why OWASP Top 10?

OWASP Top 10 is often described as a "list of vulnerabilities," but while working through it, I realized it's much more than that. It's essentially a lens for understanding how real-world web applications fail.

For someone aiming for entry-level security roles, OWASP Top 10 felt like a baseline expectation:

  • It's referenced in job descriptions
  • It's widely used by developers and security team.
  • It connects directly to real incidents and breaches

I didn't want to just know the OWASP categories — I wanted to understand how these vulnerabilities actually happen and how attackers think.

Why I Chose PortSwigger Web Security Academy

I chose PortSwigger Web Security Academy because:

  • It's created by the team behind Burp Suite
  • The labs are practical and realistic
  • he focus is on understanding application behavior, not just clicking through steps

What I liked most is that the labs don't immediately give answers. They force you to:

  • Observe application responses
  • Modify inputs
  • Think through why something works or fails

That process helped me build problem-solving confidence, which is critical in security roles.

What I Practiced (High-Level Overview)

Instead of listing every lab, I'll focus on concepts and patterns I repeatedly encountered while working through OWASP Top 10:

  • Injection vulnerabilities (like SQL Injection): Understanding how unvalidated input can alter backend queries and logic.
  • Cross-Site Scripting (XSS): Seeing how user-controlled input can be reflected or stored and executed in a browser.
  • Broken Authentication & Session Management: Observing how weak session handling or predictable tokens can lead to account compromise.
  • Broken Access Control: Learning how missing or incorrect authorization checks allow users to access data they shouldn't.
  • Security Misconfigurations: Realizing how default settings, exposed admin panels, or verbose error messages expand the attack surface.

The common theme across all of these was trust — applications often trust user input, client behavior, or internal assumptions far more than they should.

How This Changed the Way I Think About Security

Before working on these labs, I viewed vulnerabilities as isolated technical issues. After completing them, my perspective shifted:

  • Security issues are often logic flaws, not just technical bugs
  • Small oversights can have disproportionate impact
  • Attackers don't "break" systems — they abuse intended functionality

I also learned that tools are secondary. Burp Suite helped, but the real skill was:

  • Knowing what to test
  • Knowing why a response looked suspicious
  • Asking the right questions about application behavior

This mindset shift has been one of the most valuable outcomes of this learning phase.

How This Prepares Me for Entry-Level Security Roles

From an entry-level perspective, this experience directly supports roles such as:

  • Junior Application Security Engineer
  • Security Analyst (AppSec-focused)
  • Vulnerability Assessment / Security Testing roles

The biggest takeaway for me is not "I can exploit vulnerabilities," but:

  • I understand how vulnerabilities arise
  • I can reason about risk and impact
  • I can communicate security issues more clearly to developers

These are skills that matter even at the junior level.