How to Get Started in Cybersecurity (The Real Path)

A few months ago I spent a stretch testing APIs for a bank. Not "reading about security" testing — actually poking at authentication flows, authorization checks, and endpoints on a live financial product to find what an attacker would find first. That work came out of years of writing backend code, not out of a security degree. I didn't start in security. I ended up here.

Since then, the question I get most from other developers is some version of: "How do I get into cybersecurity? Where do I even start?" Most of the answers floating around online are the same recycled list — "learn Linux, get Security+, watch some YouTube videos, good luck." That's not wrong, exactly. It's just useless without an order, a reason, or a way to tell if you're actually making progress.

This is the guide I wish someone had handed me: what to actually learn, in what order, with real free resources, and a real example of what the work looks like once you're doing it — not once you've passed a quiz about it.

---

First, drop the Hollywood version

"Cybersecurity" isn't one job. It's a handful of very different jobs that get flattened into one word by movies and LinkedIn posts. Before you learn anything technical, it helps to know which room you're walking into:

• AppSec / API security — finding and fixing vulnerabilities in the software a company builds. This is where I work. Closest to regular development.
• Penetration testing / red team — hired (or contracted) to break into systems on purpose, with permission, and report what you find.
• SOC / blue team — watching logs and alerts, detecting intrusions, responding to incidents in real time.
• Cloud security — securing AWS/Azure/GCP environments: IAM permissions, misconfigured storage, network boundaries.
• GRC (governance, risk, compliance) — policy, audits, frameworks like SOC 2 and ISO 27001. Less hands-on-keyboard, more process.

You don't have to pick one on day one. But knowing they exist stops you from grinding generic "hacking" content for a year and then discovering the job you actually want is mostly reading logs, or mostly writing reports, or mostly reading code.

Pick a direction after your first month of fundamentals, not before it. You'll know a lot more about what you enjoy once you've touched a terminal a few times.

What you actually need before touching security tools

This is the part almost every "beginner guide" skips, and it's why so many people bounce off security within a month. If you don't understand how a request even reaches a server, no amount of clicking buttons in a hacking tool will make sense. You need three foundations first.

1. Comfort with Linux and the command line

Nearly every security tool is built for Linux first. You don't need to master it — you need to stop being afraid of a terminal. The single best way to build this is OverTheWire's Bandit wargame, a free set of levels where each one teaches you a real command by making you use it to find the password for the next level. It's the closest thing to "learn Linux by actually needing it" that exists for free.

2. Basic networking

You need to understand, at least at a working level, how DNS resolves a domain, what a TCP handshake is, what ports and protocols are, and how HTTP requests and responses are structured. Professor Messer's free Network+ course covers this thoroughly and is the same material people pay for in bootcamps.

3. One programming language, well enough to read and write small scripts

You don't need to be a senior engineer. You need to be able to write a script that sends a request, parses a response, and loops over a list. Python is the default choice in security for a reason — most tools are written in it or scriptable with it. If you already write code for a living, you're ahead here. If you don't, this step is non-negotiable — skipping it is the single biggest reason people plateau at "I can follow tutorials" and never get past it.

The real roadmap, phase by phase

Here's the order I'd actually follow if I were starting today, assuming a few hours a week. Not everything needs to be finished before moving on — phases overlap.

Phase 1 — Foundations (weeks 1–4)

• Finish OverTheWire Bandit (all levels).
• Work through Professor Messer's Network+ videos, at least the core sections on TCP/IP, DNS, and HTTP.
• If you don't already know Python: build three or four tiny scripts (a port scanner using sockets, a script that hits an API and prints the response, a simple file parser). Don't buy a course for this — the official Python tutorial is enough to get moving.

Phase 2 — Learn how the web actually breaks (weeks 4–10)

This is the phase that made everything click for me. PortSwigger's Web Security Academy is free, built by the team behind Burp Suite, and is the single best resource in security education, full stop. It explains each vulnerability class — SQL injection, XSS, authentication flaws, access control, SSRF — and then gives you a real, deliberately vulnerable web app to exploit it in. Reading about a vulnerability and exploiting one yourself are not the same skill, and this is where you build the second one.

Alongside it, read the OWASP Top 10. It's short, it's free, and it's the shared vocabulary the entire industry uses. If you can explain what broken access control and SSRF are in your own words, you're already ahead of a lot of people with certificates.

Phase 3 — Practice in structured environments (weeks 8–16, overlapping with Phase 2)

• TryHackMe — start with the "Pre Security" and "Jr Penetration Tester" paths. Guided, beginner-friendly, cheap.
• HackTheBox — once TryHackMe feels easy, move here. Less hand-holding, closer to real conditions.
• picoCTF — free, beginner-oriented capture-the-flag competition run by Carnegie Mellon. Great for building problem-solving speed.

Do these in order, not all at once. Bouncing between platforms before you've built any pattern recognition just makes everything feel equally confusing.

Phase 4 — Pick a lane and go deep

By now you'll have a gut feeling for what you enjoy. If it's web apps and APIs, go deeper into AppSec. If it's breaking into networks and systems, lean into pentesting. If you liked reading logs and piecing together what happened, look at SOC/blue team work. This is also the point where a certification starts to actually mean something, because you'll have context for what it's testing.

What API security testing actually looks like (a real example)

Since people ask specifically about this — here's what testing financial APIs actually involved, without getting into anything specific to the client. Most of the real findings weren't exotic. They mapped almost exactly onto the OWASP API Security Top 10:

• Broken Object Level Authorization (BOLA): can user A change the ID in a request URL or body and access user B's data? This is, by far, the most common serious bug in real-world APIs. It sounds simple. It's shocking how often it's missed.
• Broken authentication: are tokens validated properly? Do expired sessions actually expire? Can a password reset flow be abused to take over an account?
• Excessive data exposure: does an endpoint return the full user object — including fields the frontend never displays — when it only needed to return three fields? That "extra" data is often the actual bug.
• Rate limiting: can a login or OTP endpoint be hit thousands of times a minute? If so, brute force is on the table.
• Mass assignment: if an API blindly accepts whatever fields are sent in a JSON body, can you set a field like role or isAdmin that was never meant to be user-editable?

The tooling for this work is unglamorous: Burp Suite to intercept and replay requests, Postman to poke at endpoints methodically, and a lot of reading response bodies carefully — comparing what should be returned against what actually is. The skill isn't some special hacker instinct. It's the same skill good backend developers already have: understanding what a request is supposed to do, then checking whether the server actually enforces that.

If you've ever built an API and thought "I should double-check that a user can't just change this ID in the URL" — you already have security instincts. Testing is just doing that check systematically, on someone else's code, on purpose.

Tools worth learning early

• Burp Suite Community Edition — free, and the core tool for web/API testing. Intercept, modify, and replay HTTP traffic.
• OWASP ZAP — a free, open-source alternative to Burp with automated scanning built in.
• Nmap — network scanning. Still the standard, decades in.
• Wireshark — packet capture and inspection. Builds real intuition for what "network security" means at the byte level.
• jwt.io — decode and inspect JSON Web Tokens. You'll use this constantly once you're looking at real APIs.

Certifications: what's worth it, honestly

This is where most guides either oversell every cert or dismiss all of them. Neither is honest. Here's what I'd actually tell someone:

• CompTIA Security+ — genuinely useful for getting past HR filters at your first job, especially in the US, where it's often a listed requirement for government-adjacent roles. It's broad and shallow. Treat it as a resume checkbox, not proof of skill.
• eJPT (eLearnSecurity Junior Penetration Tester) — affordable, fully practical (you're tested in a live environment, not multiple choice), and a genuinely good next step after the roadmap above. Better signal-to-cost than most entry certs.
• OSCP — respected industry-wide, but it is not a beginner certification, despite how it's often marketed. Don't attempt it until the fundamentals above are solid and you've done real hands-on practice for months. Going in too early just means an expensive, demoralizing fail.
• CEH (Certified Ethical Hacker) — widely known outside the industry, less respected inside it. Practitioners often see it as expensive and mostly theoretical compared to eJPT or OSCP. I wouldn't prioritize it unless a specific job posting explicitly requires it.

None of these replace proof of work. A cert says you passed a test. A writeup, a bug report, or a small tool says you can actually do the thing.

How to prove you can do this before anyone's paying you

Nobody hires "I read about security for six months." They hire evidence. Build a paper trail while you learn:

• Publish writeups. Every TryHackMe/HackTheBox box or CTF challenge you solve, write up how you solved it — even briefly. This does two things: it forces you to actually understand the solution instead of just clicking through it, and it becomes a public portfolio.
• Try bug bounties, even for low-severity findings. HackerOne and Bugcrowd host programs where companies explicitly authorize you to test their live systems. A single accepted report, even a small one, is worth more on a resume than a stack of unfinished courses.
• Keep a public GitHub. A small script — a scanner, a checker, an automation tool — shows you can build, not just consume.
• Learn to write a clear report. This is the most underrated skill in the entire field and almost nobody practices it. Finding the bug is half the job. Explaining it clearly enough that a developer who's never heard of it can understand the risk and fix it — that's the other half, and it's the half that actually gets you hired and rehired.

Mistakes I'd tell a beginner to skip

• Buying certifications before fundamentals. A cert on top of a shaky foundation just means you memorized answers you don't understand.
• Grinding CTFs without writing anything down. Solving forty boxes with nothing to show for it is weaker than solving five and documenting each one well.
• Skipping the scripting step. You will hit a wall fast if you can't automate anything yourself.
• Ignoring report writing. Technical skill gets you the finding. Communication gets you the job.
• Testing anything without explicit permission. Everything above — bug bounty programs, TryHackMe, HackTheBox — is scoped and authorized. Testing systems you don't have permission to test isn't a gray area, and it isn't how anyone I know actually broke into this field.

A concrete first 90 days

1. Weeks 1–2: Finish OverTheWire Bandit. Start Professor Messer's Network+ videos.
2. Weeks 3–4: Finish Network+ fundamentals. Write your first three Python scripts.
3. Weeks 5–8: Start PortSwigger Web Security Academy — work through the SQL injection, XSS, and access control sections. Read the OWASP Top 10 alongside it.
4. Weeks 9–12: Start TryHackMe's "Pre Security" and "Jr Penetration Tester" paths. Publish your first two writeups. Skim the OWASP API Security Top 10 if APIs interest you.

That's it. Not eighteen tools, not a $2,000 bootcamp, not a certificate before you've written a line of Python. Just a sequence that builds on itself, using mostly free resources, ending with something you can actually show someone.

The honest version

I didn't plan a path into security. I wrote backend code for years, got pulled into testing an API for security issues, and realized the instincts I already had — "what happens if this ID is swapped," "what does this endpoint leak that it shouldn't" — were most of the job. If you already build software, you're closer to this than the intimidating "hacker" framing makes it feel.

If you don't build software yet, the roadmap above gets you there in the same order I'd walk a friend through it: foundations first, breakage second, proof of work always. Skip the parts that feel like busywork. Don't skip the parts that feel slow — those are usually the ones actually building the skill.