Application Security, Attack by Attack
Start at the password store and work outward through the attacks that keep landing, then finish on why known vulnerabilities sit unpatched for years.
11 articles · about 99 min in total
Start with Password Hashing: bcrypt vs Argon2id, and Why Fast Is a BugSecurity checklists fail because they list controls without the attack. Once you know what the attacker actually does, the control stops being a rule to comply with and becomes the obvious thing to do.
So this path is organized by attack and it starts at the password store, because that is where a breach turns from embarrassing into catastrophic. It is also the one place in computing where fast is a defect: bcrypt and Argon2id are deliberately slow, and understanding why that inversion exists explains most of what follows.
The middle of the path covers controls that were adopted and then quietly stopped working. Teams moved to JWTs to avoid session state and then added a denylist. Browsers shipped SameSite cookies and a lot of applications got CSRF protection without noticing the three holes it leaves.
The end is uncomfortable and deliberate. Most organizations know about their unpatched vulnerabilities and do not fix them, and the reasons are structural rather than technical. Any security plan that assumes otherwise is planning for a company that does not exist.
Key takeaways
- Password hashing is the one context where a fast algorithm is a defect, which is why bcrypt and Argon2id are deliberately slow and memory-hard.
- SameSite cookie defaults removed most CSRF exposure but leave gaps around top-level navigation with side effects, subdomain trust and non-conforming clients.
- Server-side request forgery escalates through cloud metadata endpoints, which is why network-level egress restrictions matter more than input validation alone.
- Known vulnerabilities usually remain unpatched for organizational reasons rather than technical ones, so remediation plans have to account for ownership and change risk.
Step 1: Password Hashing: bcrypt vs Argon2id, and Why Fast Is a Bug
A password hash is the one function in your codebase you want to be slow. One RTX 4090 runs MD5 at 164 billion guesses a second and bcrypt at 184 thousand. Here are the parameters OWASP, RFC 9106 and NIST actually publish, and why memory cost is the setting that hurts an attacker most.
Sep 1, 2026 · 9 min read
Step 2: If Your JWT Needs a Denylist, You Have Rebuilt Sessions With Extra Steps
JWTs are the default choice for new apps and usually the wrong one. The reason is revocation: there is no row to delete. And the standard fix, a server-side denylist, reintroduces the database lookup that was the entire point of going stateless.
Jul 29, 2026 · 9 min read
Step 3: Your App Got CSRF Protection in 2020 Without Doing Anything. Three Holes Remain.
Chrome made SameSite=Lax the default and most CSRF vulnerabilities quietly stopped working. That is real protection nobody implemented, and it leaves three specific gaps, one of which turns on the fact that SameSite was never about origins in the first place.
Jul 29, 2026 · 8 min read
Step 4: SSRF Borrows Your Server's Network Position, and Validating the Hostname Does Not Help
The Capital One breach was 100 million records from one server-side request. The reason the obvious fix fails is subtler than a bad blocklist: you check a hostname, then you resolve it again to make the request, and DNS is free to answer differently the second time.
Jul 29, 2026 · 9 min read
Step 5: OWASP API Security Top 10: A Developer's Practical Defense Guide
Walk through every OWASP API Security Top 10 vulnerability with real attack examples and code-level mitigations you can ship this week.
Mar 12, 2026 · 10 min read
Step 6: The Pros and Cons of reCAPTCHA v3
reCAPTCHA v3 dropped the checkbox and the traffic-light puzzles in favor of a silent score from 0 to 1. That is a real usability win and a real set of tradeoffs. Here is what you actually sign up for.
Jan 19, 2021 · 4 min read
Step 7: A Zero Trust Security Checklist That Actually Works
Zero trust is less of a product you buy and more of an architectural posture you build over time. Here's a prioritized checklist that gets you to meaningful security improvements without paralyzing the engineering team.
Jan 22, 2026 · 7 min read
Step 8: OSINT for Security Professionals: Techniques, Tools, and Ethical Boundaries
A professional guide to open-source intelligence gathering: passive recon, threat actor profiling, and integrating OSINT into your security program.
Feb 9, 2026 · 10 min read
Step 9: Tabletop Exercises Your Security Team Should Run
Five simulation scenarios that make the difference between chaos and calm during a real incident. Each one designed to expose gaps that your playbooks miss.
Jan 13, 2026 · 7 min read
Step 10: Why Companies Don't Fix Vulnerabilities: The Math Is Brutal
Change Healthcare's Citrix portal had no MFA. Equifax had a free patch sitting on its own internal listserv for two months before attackers walked in. Companies don't fix vulnerabilities because the expected-value math, run honestly, genuinely points at inaction, and every breach press release that reads the same is what that math actually produces.
May 11, 2026 · 15 min read
Step 11: Post-Quantum Crypto Migration: The Checklist for Teams Who Haven't Started
The deadlines are set, the standards are final, and 91% of businesses still have no roadmap. The uncomfortable truth is that you can't migrate what you can't see, so the first task isn't picking an algorithm, it's building an inventory of every place you use crypto.
May 27, 2026 · 11 min read
Frequently asked questions
- Should I use bcrypt or Argon2id?
- Use Argon2id for new systems, because it is memory-hard and therefore expensive to attack with GPUs. bcrypt remains acceptable and is far better than any general-purpose hash. Never use SHA-256 or MD5 for passwords, since their speed is exactly what an attacker wants.
- Does SameSite replace CSRF tokens?
- Mostly, but not completely. SameSite=Lax blocks the common cross-site form post and browsers now default to it. Gaps remain around top-level GET navigation with side effects, trust between subdomains, and clients that do not enforce it, so state-changing endpoints still deserve a check.
- What makes SSRF dangerous?
- Not the outbound request itself, but where it can reach. In cloud environments an attacker who can make your server fetch a URL can often reach the instance metadata service and retrieve credentials, which turns a minor bug into full account access.
- Why do companies leave known vulnerabilities unpatched?
- Because patching is a change, and changes carry risk, ownership questions and downtime. The technical fix is usually known and cheap. What blocks it is that no team owns the component, or the upgrade breaks something else, or the risk is accepted informally and never revisited.