What's Next? Continuing Your Security Journey

You've made it through the whole HTTP request journey — from the development environment, through DNS and TLS, CDN, API gateway, authentication, business logic, database, file storage, error handling, monitoring, all the way to backups. That's a lot of ground covered.

Here's the honest truth: this series scratched the surface. Intentionally. The goal wasn't to turn you into a penetration tester — it was to give you the mental model and the foundational habits that prevent the most common, most avoidable mistakes. From here, the path splits depending on where you want to go.

What This Series Covered (And What It Didn't)

The series followed a single framework: every security decision maps to a layer in the request lifecycle. That framing is genuinely useful because it tells you where to look when something goes wrong and who is responsible for what.

What it didn't cover — intentionally — is depth on any single topic. SQL injection got a paragraph; entire books exist on it. JWT got a few sentences; there are documented attacks on every part of the JWT spec. That's fine for building intuition. But if you're shipping to real users, some of these topics deserve more of your time.

The highest-leverage areas to deepen, in roughly descending order of how often they bite early-stage apps:

Authentication Flows in Detail

The Basic User Authentication Strategies post covered the principles. What it didn't cover: the actual OAuth 2.0 flow in detail, the exact ways JWT can be misused (algorithm confusion attacks, weak signing keys, missing expiry validation), and the subtleties of secure session management at scale.

The Portswigger Web Security Academy has interactive labs on authentication bypass — working through those gives you a feel for how these attacks actually work, which makes you much better at defending against them. It's free and significantly better than most paid courses.

Cloud Security — IAM and Storage

If you're deploying on AWS, GCP, or Azure, the infrastructure itself is an attack surface. The most common mistakes:

IAM (Identity and Access Management): over-permissive roles, access keys committed to version control, no rotation policy, service accounts with admin-level access. The AWS IAM Best Practices documentation is worth reading in full. The same principles apply to GCP and Azure.

S3 and object storage: public buckets are still, despite years of incidents, one of the most common causes of data breaches. The rule is simple: buckets are private by default, access is via pre-signed URLs or IAM-controlled service accounts. Never make a bucket public unless you have a very specific reason and the data is truly meant to be public.

Secrets in environment variables vs. secrets managers: environment variables are a significant improvement over hardcoded credentials, but they're not the endpoint. A secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) gives you rotation, auditing, and fine-grained access control. Not essential on day one, but worth adding as the application matures.

We've written a dedicated guide that covers IAM beyond just the cloud console — from repository permissions and database users to service-to-service authentication: IAM: Identity and Access Management Is Everywhere.

CI/CD Security

Every time you push code, something builds and deploys it. That pipeline is part of your attack surface. Real incidents have happened via:

• Secrets exposed in CI logs (someone prints an env var that contains a database password)
• Malicious PRs triggering CI and accessing secrets
• Compromised build dependencies (the supply chain attacks from Third-Party Libraries apply here too)
• Over-permissive deploy tokens that can push to production

Concrete steps: use environment-scoped secrets in your CI provider (GitHub Actions secrets, GitLab CI variables), don't allow PRs from forks to access production secrets, pin your actions/images by commit hash rather than mutable tags, and add a step that runs a dependency scanner (Snyk, npm audit) on every build.

For a full walkthrough — secrets in logs, fork PR risks, OIDC-based credentials, and branch protection — see CI/CD Security: Your Pipeline Is Part of Your Attack Surface.

What OWASP Publishes Beyond the Top 10

The OWASP Top 10 is what most people have heard of. But OWASP publishes a lot more:

• OWASP Cheat Sheet Series — specific, actionable guidance on topics like authentication, input validation, cryptography, and dozens more. This is probably the most practically useful thing OWASP produces.
• OWASP Testing Guide — a methodology for testing your own application systematically.
• OWASP ASVS (Application Security Verification Standard) — a checklist of security requirements organized by severity. Useful as a review tool when you want to assess what you've missed.

If you read only one thing from OWASP, make it the Cheat Sheet Series. The individual sheets are concise and directly applicable.

Learning by Watching Real Attacks

Reading about security concepts is one thing. Seeing how actual attacks unfold is another — and it changes how you think about your own code.

HackerOne and Bugcrowd disclosed reports: public bug bounty reports where researchers describe exactly what they found and how. Reading 10–20 of these for a vulnerability class (say, IDOR) teaches you more about that vulnerability than most articles. HackerOne's disclosed reports are searchable by vulnerability type.

PortSwigger Web Security Academy: mentioned above for authentication, but it covers SQL injection, XSS, CSRF, SSRF, deserialization, and more. Each topic has a conceptual explanation and hands-on labs. The labs run in your browser — no setup required.

CVE databases and security advisories: when a library you use publishes a CVE, reading the advisory tells you exactly what went wrong. This is underrated as a learning resource. GitHub's Security Advisories and NVD are good starting points.

Tools Worth Adding to Your Workflow

Some of these have been mentioned throughout the series; worth collecting in one place:

Static analysis:

• Snyk — dependency vulnerability scanning, IDE plugin, CI integration. Free tier is sufficient for most projects.
• Semgrep — static analysis rules for common security patterns in your own code. Community rules cover OWASP Top 10 patterns.

Dynamic testing:

• OWASP ZAP — automated scanner and proxy for testing your running application. The baseline scan is easy to integrate into CI.
• Burp Suite Community Edition — the industry standard proxy for manual testing. The Community edition covers most things you need for testing your own app.

Infrastructure:

• SSL Labs — tests your TLS configuration from outside. Should be an A or A+.
• securityheaders.com — checks your HTTP security headers. Aim for A or B+ after adding the headers from the CDN post.
• Mozilla Observatory — comprehensive security assessment combining headers, CSP, cookies, and more.

The Mindset, Revisited

The series opened with Introduction to Security Mindset. It's worth coming back to that framing periodically.

Security isn't a checklist you complete once. It's a property of the system that degrades over time as the codebase grows, dependencies age, and the threat landscape shifts. The habits that matter:

• Review your dependencies regularly. Not when there's a breach — on a schedule. Monthly npm audit or Snyk scan is a reasonable baseline.
• Read your error logs. Unusual patterns (spike in 401s, repeated failures on the same endpoint) often signal something worth investigating.
• Keep up with advisories for the frameworks you use. Most have mailing lists or security announcement channels. Subscribing takes two minutes and will alert you when something needs patching.
• Test your own app. DIY Security Testing has concrete starting points. Running ZAP against your staging environment before a release is the kind of thing that catches obvious problems before they reach production.

The goal isn't perfect security — it's raising the cost of attack high enough that your application isn't the easiest target, and having enough visibility that you know when something has gone wrong.

Summary

Security is one of those skills where what you don't know can genuinely hurt you — but also one where a relatively small investment in the right fundamentals covers a lot of ground. You've already made that investment. Keep going.

Sources: OWASP Top 10, OWASP Cheat Sheet Series, Portswigger Web Security Academy, HackerOne Hacktivity