Fortify

Cross-site scripting (XSS) is a vulnerability that lets an attacker run their own JavaScript inside someone else’s browser session on your site. It is consistently one of the most common web bugs and also one of the most misunderstood. This guide makes it click: the three types, how a script ends up on your page, and how output encoding and a content security policy shut it down. It is written for developers, not specialists. In this guide What XSS is The three types: stored, reflected, DOM A concrete example Why it's dangerous The fix: output encoding Content Security Policy Framework protections and their gaps FAQ Quick answer: Cross-site scripting is when untrusted input is rendered into a page as HTML or script, so the browser runs it as code. The fix is context-aware output encoding—treat all user data as text when it reaches the page—backed by a content security policy as a second layer. What XSS is Cross-site scripting is an injection bug, closely...

SQL injection is a decades-old vulnerability that still turns up in code reviews every week, and it is one of the most damaging bugs a web app can ship. This guide shows exactly how it works with a concrete example, explains what an attacker can reach, and—most importantly—walks through the one fix that actually closes it. If you write code that talks to a database, this is the vulnerability to understand first. In this guide What SQL injection is A vulnerable query, step by step What an attacker can do The fix: parameterized queries ORMs and their limits Defense in depth How to test your own code FAQ Quick answer: SQL injection happens when user input is concatenated into a SQL query so the database treats it as code instead of data. The fix is parameterized queries (prepared statements), which send the query and the values separately so input can never change what the query does. What SQL injection is SQL injection is a flaw where untrusted input reaches the...

Password hashing is the single most important thing to get right when you store user credentials, and getting it wrong is the most damaging beginner mistake in authentication. This guide explains why you hash instead of encrypt, why salting is non-negotiable, and which algorithms to reach for in 2026. If your app stores passwords, this is the page to read before your next release. In this guide Never store passwords in plain text Hashing vs encryption Why fast hashes are bad here Salting and why it matters bcrypt, scrypt, argon2 Peppering and work factors Migrating an old password store FAQ Quick answer: Store passwords by running them through a slow, salted password-hashing algorithm—argon2id, scrypt, or bcrypt—never plain text, never reversible encryption, and never a fast hash like MD5 or SHA-256. Verify a login by hashing the input and comparing, so you never keep the original password at all. Never store passwords in plain text The first rule of password ...

The OWASP Top 10 is the security industry’s short list of the risks most likely to get a web application breached, and it is the first place I send any developer who asks where to start. This guide walks the categories that cause the most damage—in plain language, with the single most important fix for each. It is written for developers who ship features, not for auditors. In this guide What the OWASP Top 10 is Broken access control Cryptographic failures Injection Insecure design Security misconfiguration Vulnerable dependencies Auth failures How to use this list on your own app FAQ Quick answer: The OWASP Top 10 is a free, community-built list of the ten most critical web application security risks. Treat it as a prioritized checklist—lock down access control, injection, and misconfiguration first, because that is where most real breaches begin. What the OWASP Top 10 is The OWASP Top 10 is a consensus document from the Open Worldwide Application Securi...

JWT security is where a lot of otherwise-careful teams slip, because JSON Web Tokens are easy to issue and surprisingly easy to misuse. This guide covers what a JWT actually is, the mistakes that show up again and again— alg=none , weak secrets, tokens that never expire—and the practical fix for each. It is for developers using tokens for authentication who want to sidestep the well-known traps. In this guide What a JWT actually is The three parts of a token What JWTs are good (and bad) at Mistake: trusting alg=none Mistake: weak or shared secrets Expiry and revocation Where to store tokens on the client FAQ Quick answer: A JWT is a signed, base64url-encoded token whose claims anyone can read but only the holder of the key can validly sign. Good JWT security means verifying the signature with a fixed algorithm, using a strong secret or key, keeping tokens short-lived, and validating every standard claim—never trusting the token’s own header about how ...