A practical web application security checklist for growing businesses

You don’t need a 300‑control framework to dramatically reduce risk. A handful of well‑implemented controls prevents most of the issues that actually hurt growing businesses. This checklist focuses on those, mapped loosely to the OWASP Top 10.

How to use this checklist

Go control by control and mark each as done, partial or missing. Fix anything in the “access control” and “authentication” sections first. Broken access control and authentication failures are consistently among the most damaging issues.

Authentication

• Store passwords with a strong, salted hash (such as bcrypt, scrypt or Argon2); never plaintext or fast hashes.
• Offer multi‑factor authentication for accounts with elevated access.
• Rate‑limit and add backoff to login, password‑reset and token endpoints.
• Use secure, HttpOnly, SameSite session cookies; rotate session IDs on login.
• Expire sessions sensibly and invalidate them on password change.

Access control

• Enforce authorization on the server for every request; never trust the client.
• Check object‑level ownership to prevent IDOR (e.g. user A loading user B’s record by changing an ID).
• Default to deny; grant least privilege.
• Protect state‑changing requests against CSRF (tokens or same‑site cookies).
• Separate admin functionality and require re‑authentication for sensitive actions.

Input and output handling

• Use parameterised queries / prepared statements to prevent SQL injection.
• Validate and normalise input on the server; treat all input as untrusted.
• Encode output for its context to prevent cross‑site scripting (XSS).
• Constrain file uploads: type, size and storage location; never execute uploads.
• Avoid building shell commands or file paths from user input.

Transport & security headers

Serve everything over HTTPS and add a baseline of response headers. A reasonable starting point (tune per app):

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: DENY
Permissions-Policy: geolocation=(), camera=(), microphone=()

Test a Content‑Security‑Policy in report‑only mode before enforcing it, so you don’t break legitimate resources. See Mozilla’s reference for header details.

Dependencies & secrets

• Keep dependencies updated; monitor for known vulnerabilities (e.g. with your package manager’s audit tooling).
• Pin and review third‑party scripts; remove what you don’t use.
• Keep secrets out of source control and client bundles; use environment configuration.
• Rotate credentials and API keys, and scope them to least privilege.

Logging & monitoring

• Log authentication events and significant actions, without logging passwords, tokens or full personal data.
• Make sure errors don’t leak stack traces or secrets to users.
• Have a basic plan for detecting and responding to abuse.

Sources

Editorial note. Written by the Qaisi team and reviewed by our engineering practice for technical accuracy. Header examples are a starting point and must be tuned to your application. A named reviewer will be shown here once our editorial policy is published.