Resources

Free courses and references

• PortSwigger Web Security Academy: free, hands-on labs for every major web bug class. The best place to start.
• OWASP Web Security Testing Guide: a test-by-test methodology to make sure you don't skip whole areas.
• OWASP API Security Top 10 (2023): the most common ways APIs break, with examples.
• HackTricks: practical notes by technology and service. Useful when you hit something unfamiliar.

Places to practice

• OWASP Juice Shop: a deliberately vulnerable shop you run locally. Covers most of the OWASP Top 10.
• OWASP crAPI: a vulnerable API-first app. Good for BOLA, mass assignment and JWT issues.
• PentesterLab: short exercises that build from basics up to code review.
• Hack The Box and TryHackMe: full machines and guided rooms. TryHackMe is gentler to begin with.

Test method

• Create at least two users with the same role, one user per other role, and one user in a second tenant or organization. Also test with no session at all.
• Do everything as the most privileged user and record the traffic. Then replay each request as every other user and compare the response bodies, not just the status codes.
• Swap identifiers wherever they appear: path, query string, JSON body, headers. Get valid IDs from list, search and export endpoints.
• Test writes, not just reads. PUT, PATCH and DELETE often skip a check that GET has.
• Add fields the UI never sends, like role, org_id or is_admin, to create and update requests. That's how mass-assignment bugs show up.
• Try older API versions, mobile endpoints and bulk operations. The check is often missing in exactly one of them.

References and tools

• PortSwigger: access control: IDOR, privilege escalation and multi-step flaws, with labs.
• OWASP Authorization Cheat Sheet: the defender's side. Worth reading so you know what a correct check looks like.
• Autorize: a Burp extension that replays every request with a second user's session while you browse.
• VardrGate: write expected access rules as a policy and run them locally or in a configured CI job.

Finding endpoints

• Kiterunner: finds API routes using wordlists built from real API specs, not just paths.
• Arjun: finds hidden query and body parameters.
• ffuf: fast fuzzing for paths, parameters and virtual hosts.

Tokens and auth

• jwt_tool: tests JWTs for unsigned (alg: none) tokens, weak secrets, key confusion and claim tampering.
• Check what happens with an expired token, a token from another environment, and a token after logout or password change.

GraphQL

• graphw00f: identifies which GraphQL server you're talking to.
• InQL: a Burp extension that turns the schema into ready-to-send queries.
• Clairvoyance: recovers the schema even when introspection is turned off.

Proxies and wordlists

• Burp Suite Community: the standard intercepting proxy. The free edition is enough for learning and most manual testing.
• ZAP: a free, open-source alternative that's easy to script and run in CI.
• SecLists: wordlists for paths, parameters, usernames and payloads. Pairs with ffuf.

Payload references

• PayloadsAllTheThings: payloads and bypasses for each bug class, including SSRF, SSTI, XXE, deserialization and file upload.
• PortSwigger lab list: when you find a bug class in the wild, do its labs first to learn the variations.

Subdomains and hosts

• crt.sh: searches certificate transparency logs. Every certificate an organization issues names its hosts.
• subfinder and Amass: passive subdomain enumeration from many sources.
• httpx: checks which of those hosts are live, and their titles, status codes and technologies.

History and exposure

• Wayback Machine and gau: old URLs, parameters and endpoints that may still respond.
• Shodan and Censys: internet-wide scans that show exposed services, certificates and banners.
• TruffleHog: finds and verifies leaked secrets in public repositories. Report what you find, never use it.

People and organizations

• theHarvester: collects emails, names and hosts from public sources.
• OSINT Framework: a directory of OSINT tools sorted by what you're trying to find.
• Bellingcat's toolkit: investigation tools with notes on how and when to use each one.

Practice

• flaws.cloud and flaws2.cloud: short, free AWS challenges based on common real mistakes. flaws2 includes a defender track.
• CloudGoat: vulnerable-by-design AWS scenarios you deploy into your own account.

Checking your own account

• Run Prowler against it. It covers AWS, Azure and GCP and maps results to common benchmarks.
• Replace long-lived access keys with roles and short-lived credentials. Leaked keys are one of the most common ways into a cloud account.
• Block public storage at the account level, and keep a written list of the exceptions.
• Turn on audit logging (CloudTrail or the equivalent) in every region, including ones you don't use.

Authorization

• Deny by default, and make the decision in one shared place. Checks scattered across handlers are where one gets forgotten.
• Take the user and tenant from the session, never from a request field the client controls.
• Check ownership on every object access, including updates, deletes, bulk actions and exports.
• Random IDs aren't access control. They leak through URLs, logs and shared links.
• Write the expected rules down and test them automatically, so a regression fails the build.

Authentication and sessions

• Give admins phishing-resistant MFA (passkeys or security keys). SMS codes can be phished.
• Rate-limit login by account and by IP instead of locking accounts. Lockouts let anyone lock out your users.
• Return the same response for "no such user" and "wrong password", and take the same time to do it.
• Issue a new session ID at login and whenever privileges change. Make reset tokens single-use and short-lived.
• Hash passwords with Argon2id or bcrypt. See the OWASP Cheat Sheets for current settings.

Code, secrets and dependencies

• Scan commits for secrets with Gitleaks before they're pushed. Once a secret reaches a public repo, rotating it is the only fix.
• Look up dependencies on OSV, and fix anything in CISA's Known Exploited Vulnerabilities list first.
• Add Semgrep rules for the mistakes your team actually makes, not just the default rule pack.
• Use the OWASP ASVS when you need a real requirements list rather than a checklist.

Servers and headers

• SSH: keys only (PasswordAuthentication no), no root login, and an alert when any authorized_keys file changes. See the write-up. Check your config with ssh-audit.
• Set a Content-Security-Policy with frame-ancestors. Start in report-only mode so you don't break the site.
• HSTS, X-Content-Type-Options: nosniff and Referrer-Policy: strict-origin-when-cross-origin are safe defaults almost everywhere.
• Send Cache-Control: no-store on responses that contain personal or account data.

MITRE ATT&CK

ATT&CK gives attacker behavior shared names. Use it to see which techniques you can detect and which you can't.

Sigma

Sigma is a rule format that works across SIEMs, with thousands of community rules. Read a few before writing your own.

Atomic Red Team

Atomic Red Team runs small tests mapped to ATT&CK, so you can check that an alert actually fires instead of assuming it does.