Breaking Into Security Engineering: The Self-Study Guide

Complete Resource List

Everything you'll need for this entire roadmap, organized by type. Bookmark this section — you'll come back to it constantly.

Training Platforms

Vulnerable Applications (Practice Targets)

Tools

Reference Documentation

Books

Podcasts

YouTube Channels

Certifications — Optional. Experience > Certs, But These Help

Total Budget

You can go from zero to employable on $0. The paid resources save time, not money.

Questions to Ask Yourself Before Starting

Be honest. There are no wrong answers — they just shape your path.

About your goal

• Do I want offensive security (finding/exploiting vulnerabilities) or defensive security (detecting/responding to attacks)? This guide focuses on offensive/AppSec.
• Am I targeting an internal transfer or an external role?
• What's my realistic timeline — 6 months, 12 months, 18 months?

About your current skills

• Can I write a basic Python script from scratch? (If no → start at Phase 0)
• Do I understand how websites work under the hood — HTTP requests, cookies, APIs? (If no → start at Phase 0)
• Am I comfortable in a Linux terminal? (If no → start at Phase 0)
• Have I ever used browser DevTools to inspect network traffic? (If no → that's your first homework)

About your time

• How many hours per week can I realistically commit? (5 hrs/week is fine — it just extends the timeline)
• Am I in school? Can I align coursework with this roadmap?
• When do I study best — morning, evening, days off?

About your motivation

• Am I doing this because it pays well, or because I'm genuinely curious about how things break? Curiosity sustains you. Money doesn't.
• Am I okay with feeling stupid regularly? Every security engineer feels this. The field is too broad for anyone to know everything.

The Roadmap: 6 Phases

Phase 0 Foundation Months 1–2

Skip this phase if you can honestly say yes to all of these:

• I can write a Python script that makes an HTTP request and parses the JSON response
• I can navigate a Linux terminal without Googling every command
• I can explain the difference between authentication and authorization
• I know what HTTP cookies are and how they work

Linux

• Install a VM: Ubuntu or Kali Linux
• Get comfortable with: grep, find, curl, netstat, chmod, ps, cat, less, pipe operators
• Complete: TryHackMe — Linux Fundamentals (free)

Python

• Learn the requests library — you'll use it constantly
• Write scripts that make HTTP requests, parse JSON, read/write files
• Automate something tedious — anything. File renaming, log parsing, API polling.

HTTP and Networking

• Read: MDN — HTTP Overview
• Understand HTTP methods (GET, POST, PUT, DELETE) and when each is used
• Learn headers: Authorization, Cookie, Content-Type, Origin, Referer
• Understand cookie flags: HttpOnly, Secure, SameSite, Domain, Path
• Know the difference between authentication (who are you?) and authorization (what can you do?)
• Practice: Open browser DevTools → Network tab → browse any website → read the requests

Setup Your Lab

Install all of these before moving to Phase 1:

• Burp Suite Community Edition
• Obsidian
• GitHub account
• Linux VM (Ubuntu or Kali)

Phase 1 Web Vulnerabilities Months 2–4

This is where you learn what security engineers actually find and fix. Don't memorize definitions — understand why each vulnerability exists.

The Framework

For every vulnerability class, answer these four questions:

1. What assumption did the developer make? (Every vulnerability is a broken assumption)
2. How does an attacker exploit that assumption?
3. What's the real-world impact?
4. How do you fix it?

IDOR (Insecure Direct Object Reference)

The single most common vulnerability. If you learn one thing well, learn this.

Application lets you access other people's data by changing an ID in a request. Developer assumed nobody would change the ID. They were wrong.

• Study: PortSwigger — Access Control Vulnerabilities
• Read: HackerOne Hacktivity — search "IDOR"
• Watch: PwnFunction — IDOR Explained

XSS (Cross-Site Scripting)

Injecting JavaScript into a page that other users see and execute. Three types: Reflected (in URL), Stored (in database), DOM-based (client-side only). Developer assumed user input would always be text, not code. Wrong.

• Study: PortSwigger — Cross-Site Scripting
• Watch: PwnFunction — XSS Explained

CSRF (Cross-Site Request Forgery)

Tricking a logged-in user's browser into making requests they didn't intend. Developer assumed that valid cookies = intentional request. Wrong — browsers send cookies automatically.

• Study: PortSwigger — CSRF

SSRF (Server-Side Request Forgery)

Tricking the server into making requests to internal resources you can't reach directly. Developer assumed users would only submit URLs pointing to public resources. Wrong.

• Study: PortSwigger — SSRF

SQL Injection

Injecting database commands through user input. Developer assumed input would be treated as data, not commands. Wrong.

• Study: PortSwigger — SQL Injection
• Watch: LiveOverflow — SQL Injection

Broken Authentication and Authorization

Auth = who are you? Authz = what can you do? Most real-world bugs are authorization failures — the system knows who you are but doesn't properly restrict what you can access.

• Study: PortSwigger — Access Control and Authentication

Phase 2 Code Review Months 4–7

This is the skill that gets you hired. Security engineer interviews (especially at Amazon) include a timed code review: ~200 lines of code, 45 minutes, find everything.

The 8-Point Checklist

Use this every time you review code:

1. Entry Points — Where does user input enter?
2. Data Flow — Where does that input travel through the code?
3. Trust Boundaries — Where does data cross from untrusted to trusted context?
4. Dangerous Sinks — Where does input get used in dangerous operations? (SQL queries, HTML output, system commands, file paths)
5. Sanitization — Is the input cleaned before reaching the sink? Is it done correctly?
6. Auth Checks — Does the code verify both WHO is making the request and WHETHER they're allowed?
7. Error Handling — Do error messages leak internal details?
8. Crypto — Are secrets hardcoded? Are passwords hashed properly? Is HTTPS enforced?

What to Look For (by language)

• Python: f-strings in SQL queries, os.system() with user input, pickle.loads() with untrusted data, open() with user-controlled paths
• Java: String concatenation in SQL (vs PreparedStatement), direct user input in response output, XML parsing without disabling external entities, ObjectInputStream.readObject()
• JavaScript/Node.js: eval() with user input, Object.assign() merging user data into config, fs operations with user-controlled paths, innerHTML with user input

How to Practice

• Browse GitHub Security Advisories — read the description, find the vulnerable code BEFORE looking at the fix
• Review open-source projects you use — even your own code
• Write up every finding: what's the bug, why it's dangerous, how to fix it
• Book recommendation: The Web Application Hacker's Handbook — Chapters 6–18 are code review gold

Phase 3 Hands-On Exploitation Months 7–9

Theory is necessary. Practice is what makes it stick.

Lab Progression

1. PortSwigger All Labs — Target: 80+ completed. Start Apprentice → Practitioner → Expert.
2. PentesterLab — "Essential" and "White" badges.
3. OWASP Juice Shop — Install locally, work through the challenges.
4. DVWA — Practice at increasing security levels.
5. HackTheBox Academy — Structured modules.

Rule: if stuck for 30 minutes, read the solution. Learning the technique matters more than struggling.

Burp Suite Mastery

• Proxy — Intercept and modify live HTTP traffic
• Repeater — Replay and tweak individual requests
• Intruder — Automated testing (fuzzing, brute force)
• Decoder — Encode/decode Base64, URL encoding, etc.

Write Professional Reports

For every significant finding, write it up in this format. Save every write-up — this is your portfolio.

Phase 4 AI/ML Security Months 9–11

Almost no candidates have this knowledge. It immediately sets you apart.

Why This Matters

Every major company is integrating AI. Security engineers who understand AI-specific vulnerabilities are rare and in demand. This is your competitive edge.

What to Learn

Prompt Injection — The "SQL injection of AI." Same root cause: mixing data with instructions.

• Direct: Telling an LLM "Ignore your instructions and do X"
• Indirect: Hiding malicious instructions in data the LLM processes

OWASP Top 10 for LLM Applications:

1. Prompt Injection
2. Insecure Output Handling
3. Training Data Poisoning
4. Model Denial of Service
5. Supply Chain Vulnerabilities
6. Sensitive Information Disclosure
7. Insecure Plugin Design
8. Excessive Agency
9. Overreliance
10. Model Theft

Practice

• Gandalf (free) — Progressive prompt injection challenges. Try to make the AI reveal its secret password through increasingly defended levels.
• Read the full OWASP LLM Top 10 document
• Think about how AI amplifies traditional vulnerabilities: chatbot with SSRF capability, AI assistant leaking data via prompt injection, code generation tools introducing vulnerabilities

Phase 5 Interview Prep Months 11–12

Portfolio Requirements

By this point you should have:

• 10+ vulnerability write-ups (from labs and practice)
• 5+ code review analyses
• 80+ PortSwigger labs completed
• At least 1 PentesterLab badge
• Organized notes in Obsidian
• A GitHub profile with your write-ups and any tools you've built

Security Engineer Interview — Typical Structure

Interview Tips

• Talk constantly. They want your thought process, not just your answers.
• Start broad, go deep. Skim the code first (5 min), identify the architecture, then trace user input.
• Prioritize findings. Remote Code Execution > SQL Injection > XSS > Info Disclosure. Show you understand severity.
• Suggest fixes. Don't just find problems — explain how to fix them.
• It's okay to not know. Say "I'm not sure, but here's how I'd approach figuring it out." That's what real security engineers do.

Study Tips

Time-Bucket Your Minutes

If You're in School — Double-Dip

• Programming assignments → review your own code for vulnerabilities
• Networking class → apply SSRF and segmentation concepts
• Database class → practice SQL injection thinking
• Capstone project → make it security-related (build a scanner, a secure auth system, etc.)

The Most Important Rule

Consistency beats intensity. 1 hour every day beats 7 hours on Sunday. Block it on your calendar. Protect that time.

Honest Expectations

This will work if you:

• Show up consistently (even when it's boring or hard)
• Actually do the labs (reading about security is not doing security)
• Write things down (if you didn't document it, you didn't learn it)
• Ask for help when stuck (security people love helping people who are doing the work)

This will be hard because:

• The volume of material is large
• Some concepts won't click until you see them in practice — that's normal
• Imposter syndrome is real and hits everyone — push through it
• Balancing work, life, and study takes discipline

Timeline (flexible):

• 8–10 hrs/week → ~12 months
• 5–6 hrs/week → ~15–18 months
• Less than 5 hrs/week → ~18–24 months (still worth it)

The only wrong speed is stopped.

Your First 5 Actions

Do these this week:

1. Install Burp Suite Community and intercept your first HTTP request
2. Download Obsidian and create a vault called "Security Study" with folders: Vulnerabilities, Labs, Code Review, Interview Prep, AI Security
3. Open PortSwigger Web Security Academy and complete your first lab (any lab)
4. Read one HackerOne report — don't worry if you don't understand everything yet
5. Block 1 hour/day on your calendar for study — treat it like a class

The hardest part is starting. If you're reading this, you've already done that.

What Comes Next: Apply Everything Through Bug Bounty

You've built the knowledge. You've completed the labs. You've written the reports. Now it's time to use all of it against real systems — and get paid for it.

Bug bounty programs are how companies invite security researchers to find and responsibly report vulnerabilities in their products in exchange for monetary rewards. This is real-world security engineering — not CTF challenges with known solutions, but live production systems where you're finding bugs nobody has found before.

This is also the single best way to build a portfolio that stands out. Hiring managers can tell the difference between "I completed labs" and "I found and reported a real vulnerability in a production system."

The Major Platforms

CWEs You Should Know Cold

Every vulnerability you report gets classified by CWE. Knowing the CWE landscape means you can systematically hunt instead of randomly testing.

Getting Started with Bug Bounty

1. Pick ONE program on HackerOne or Bugcrowd. Choose something you actually use — you already understand the product.
2. Read the scope carefully. Out-of-scope findings waste your time and the company's.
3. Start with access control testing (IDOR/authorization) — it's the highest-signal, lowest-competition vulnerability class for new researchers.
4. Read disclosed reports from your target program. Understand what they've already fixed — it tells you what their codebase is vulnerable to.
5. Write quality reports. Use the format from Phase 3. Clear reproduction steps, real impact, suggested fix. Good reports build reputation, which unlocks private programs with less competition and higher payouts.

Bug bounty is where everything in this guide comes together. Your Linux skills, your Python scripts, your Burp Suite mastery, your code review instincts, your understanding of how vulnerabilities work — it all applies here, against real targets, for real money.

The $100k Blueprint: @Rhynorater's Proven Path

Phase 1 — Learn the Basics (Month 1–1.5)

Before touching a target, build a solid mental model of everything you'll be attacking:

• HTTP — methods, headers, cookies, status codes, how requests flow
• Browsers — how they work, security constraints (same-origin policy, CORS, CSP)
• Web architecture — APIs, reverse proxies, cloud infrastructure
• Server-side — MVC structure, routing and handlers, API design patterns
• Client-side — JavaScript, HTML, CSS and how browsers execute them

Estimated time: 1–1.5 months of full-time study.

Phase 2 — First Bugs: Access Control & IDORs (Month 2+)

Start learning privilege escalation bugs, client-side access control bugs, IDORs, and paywall bypasses via PortSwigger Academy and Hacktivity reports.

After covering each bug type, switch your time to 20% hacking / 80% learning. At this stage, expect 1–5 bugs per month at ~$750 each — roughly $2,250/month.

Phase 3 — Expand: XSS, CSRF, SSRF (Months 3–4)

After completing the access control bug types, shift to 40% hacking / 60% learning and add XSS, CSRF, and SSRF to your repertoire.

At this split, expect roughly 7 bugs/month at $750 each = $5,250/month. That's about one bug every 10 hours of hacking.

Phase 4 — Finish PortSwigger + Hacktivity (Months 5–6)

Complete every topic on PortSwigger Web Security Academy and read through all of Hacktivity. Then shift to 80% hacking / 20% learning. The learning at this stage focuses on code review and specialty subjects like postMessage abuse.

Result: 12+ bugs/month at $750–$1k each ≈ $9k/month starting month 6. Total earned so far: ~$15,500.

Phase 5 — 100% Hacking to Close the Year (Months 8–12)

Go full hacking mode. At this point your methodology is solid and your bug radar is sharp.

Target: 15–20 bugs/month at $1k each. That's $15–20k/month across 5 months.

The Numbers

Projected year-1 total: ~$103,000 (realistically ~$90k accounting for dupes and bounty variance). These figures are based on Rhynorater's actual HackerOne performance stats, scaled to full-time.

After months 8–12, return to a 90% hacking / 10% learning split indefinitely. You never stop learning — you just stop letting it dominate your time. — @Rhynorater