Web security terms explained in plain language. No jargon. No PhD required.
When an attacker sneaks database commands into your app's input fields. Imagine someone typing a magic word into a search box that makes your database hand over all its secrets.
Example attack
A login form where typing ' OR 1=1 -- in the password field bypasses authentication entirely.
How to prevent
Use parameterized queries or an ORM. Never concatenate user input into SQL strings.
When an attacker injects malicious JavaScript into your website that runs in other users' browsers. It's like someone slipping a fake note into a bulletin board that steals everyone's wallet who reads it.
Example attack
A comment field where typing <script>steal(cookies)</script> runs code in every visitor's browser.
How to prevent
Escape all user-generated content before rendering. Use Content Security Policy (CSP) headers.
Tricks a logged-in user into performing actions they didn't intend. It's like someone forging your signature on a bank check while you're already authenticated at the bank.
Example attack
A malicious email with a hidden image tag that triggers a money transfer on your banking site.
How to prevent
Use CSRF tokens on forms. Verify the Origin/Referer header on state-changing requests.
When your secret keys (API tokens, database passwords, etc.) are accidentally published in your code. It's like leaving your house key under the doormat — everyone knows to look there.
Example attack
Pushing a .env file to a public GitHub repo with your Stripe secret key inside.
How to prevent
Use environment variables. Add .env to .gitignore. Rotate keys if they've been exposed.
Trying every possible password combination until one works. It's like a burglar trying every key on a huge keyring until one opens your door.
Example attack
An automated script trying 10,000 common passwords against your login endpoint in minutes.
How to prevent
Rate limit login attempts. Require strong passwords. Add multi-factor authentication (MFA).
The ten most critical web application security risks, published by the Open Web Application Security Project. Think of it as the 'top 10 most wanted' list for web vulnerabilities.
Example attack
Includes injection attacks, broken authentication, sensitive data exposure, and more.
How to prevent
Use the OWASP Top 10 as a checklist when building and reviewing your web app.
Encryption that protects data between your user's browser and your server. The padlock icon in the browser. Without it, anyone on the same Wi-Fi can read everything your users send.
Example attack
A login page served over HTTP (no padlock) — passwords are sent in plain text.
How to prevent
Always use HTTPS. Get a free certificate from Let's Encrypt. Monitor expiry dates.
Authorized simulated attacks on your app to find vulnerabilities before real attackers do. It's like hiring someone to try to break into your house to find weak spots.
Example attack
A security tool probing your /admin, /api/users, and /graphql endpoints without authentication.
How to prevent
Run pen tests regularly. Fix findings promptly. Retest after fixes.
Restricting how many requests a user can make in a given time period. It's like a bouncer at a club — only so many people can enter per hour.
Example attack
Allowing only 5 login attempts per minute per IP address.
How to prevent
Implement rate limiting on all public endpoints, especially authentication routes.
HTTP response headers that tell browsers how to behave securely. Think of them as safety instructions your server gives to every visitor's browser.
Example attack
X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, Content-Security-Policy.
How to prevent
Add security headers to your server config. Use tools like securityheaders.com to check.
When a package you installed (npm, pip, etc.) has a known security flaw. It's like buying a lock from a store, then finding out that model has a master key anyone can buy.
Example attack
Using an outdated version of lodash with a prototype pollution vulnerability.
How to prevent
Keep dependencies updated. Run npm audit regularly. Use tools like SafeLaunch to scan.
Authentication = proving who you are (login). Authorization = proving what you're allowed to do (permissions). One checks your ID, the other checks your access badge.
Example attack
A user can log in (authenticated) but shouldn't be able to access the admin panel (not authorized).
How to prevent
Always check both. Don't assume a logged-in user is allowed to do everything.