Web app security isn't about hiring a hacker to test your app or reading OWASP documentation — it's about making sure your dev team has covered five basics: passwords are never stored in plain text, every piece of user input is treated as untrusted, requests are rate-limited, security headers are turned on, and sessions expire and get invalidated properly. You don't need to understand the code to verify these are in place. You need to know what to ask for, and what a real "yes" should sound like. This checklist gives you exactly that — no security background required.
Authentication done right: no plain-text passwords, ever
If your dev team can look up a user's password by querying the database directly, that's an immediate red flag. Passwords should be hashed with a modern algorithm — bcrypt, argon2, or scrypt — and salted, so two identical passwords never produce the same stored value. That means even if your database is ever exposed, the passwords in it are effectively useless to whoever stole them. Just as important: sessions and login tokens need to expire, get invalidated on logout, and use secure, httpOnly cookies so they can't be lifted by a script running in the browser.
Input validation: treat everything a user types as untrusted
Every text box, upload field, and URL parameter on your site is a door. "Never trust user input" means the app checks and cleans every piece of data that comes in — on the server, not just in the browser, since browser-side checks can be bypassed entirely by anyone who knows how. Skipping this is how attackers pull off SQL injection (tricking your database into running commands it shouldn't) and cross-site scripting (sneaking malicious code into pages other users see). Proper validation isn't a one-time task; it's a discipline applied to every form and every API endpoint your app exposes.
Rate limiting: stopping abuse before it starts
Without a limit on how many requests one visitor can make, your app is exposed to three common problems: brute-force attacks that guess passwords by trying thousands of combinations, scraping bots that copy your content or pricing at scale, and simple overload that slows the site down for everyone else. Rate limiting caps how many login attempts, form submissions, or API calls a single IP address or account can make in a given window, and locks out or slows down anyone who crosses it.
Security headers: small settings, real protection
Security headers are instructions your server sends to the browser about how to behave, and they close off entire categories of attack for almost no engineering cost. A Content-Security-Policy header stops malicious scripts from running on your pages. HSTS forces every visitor onto an encrypted connection. X-Frame-Options and X-Content-Type-Options stop your site from being embedded in a disguised frame or having its files misread by the browser. You don't need to understand the syntax — you just need to know your team has actually turned them on.
How to ask your dev team the right questions
You don't need to be technical to verify this work — you need to ask specific, closed questions and expect specific, direct answers back:
- Are passwords hashed and salted, or could anyone with database access read them directly?
- Is every form and API input validated on the server, not just in the browser?
- Is there rate limiting on login, signup, and search endpoints?
- Are security headers like CSP and HSTS turned on — can I confirm it myself with a free online header checker?
- Do sessions expire, and are they invalidated immediately on logout or password change?
- When was this last reviewed, and by whom?
If a question gets a vague answer
A team that has actually built these in will answer each question in one sentence, without hesitation. Vague answers, or "we'll add that later," mean the basics aren't done yet — worth fixing before launch, not after an incident.
Frequently asked questions
Do I need to hire a security expert to check all this?
No — a free tool like a security-headers checker confirms the headers in seconds, and the other items are answered directly by your dev team. If they hesitate or can't explain it in plain language, that itself is a signal.
Is HTTPS enough to make my web app secure?
HTTPS encrypts data in transit, which matters, but it's only one piece. It doesn't stop injection attacks, brute-force login attempts, or a poorly built session system — you still need the other basics covered separately.
How much does it cost to add these protections?
Very little if they're built in from the start — most are standard practice, not extra features. It gets expensive only when a team has to retrofit them after launch, or after an incident forces the issue.
What's the single biggest mistake to watch for?
Trusting client-side validation alone. If your dev team says the browser "checks" the input, ask whether the server checks it too — that one gap causes more real-world breaches than any other single mistake.