Checklist · Security
Web Application Security Checklist
FreeA release checklist for web apps and APIs, organised around the OWASP Top 10:2025 and the OWASP cheat sheets. Each check tells you how much it matters and exactly how to confirm it is done, from access control and sessions to headers, dependencies, logging and file uploads.
Written by Tauseef Fayyaz8 chapters, 35 checksAbout 20 minReviewed 12 October 2026What you will learn
8 chapters · about 20 min
1Access control (A01)Broken access control is the top risk in the 2025 list. These checks make sure every request is authorised on the server, for the right user and the right object.5 checks · 3 min
- 1Authorize every request on the server and deny by default
- 2Check ownership of every object a user reads or changes
- 3Protect admin and internal functions with a role check
- 4Validate URLs your server fetches on behalf of users
- 5Allow only known origins in your CORS policy
5 in this chapterOpen this chapter2Authentication and sessions (A07)How you store passwords, slow down guessing and manage sessions decides whether one leaked password or cookie becomes an account takeover.5 checks · 3 min
- 1Hash passwords with Argon2id, scrypt or bcrypt
- 2Rate limit sign-in and offer multi-factor authentication
- 3Issue a new session id on login and kill it on logout
- 4Make password reset tokens single use and short lived
- 5Reject common and breached passwords instead of forcing complexity rules
5 in this chapterOpen this chapter3Injection (A05)Injection happens when user input is treated as part of a query or command. These checks keep data and code apart.4 checks · 2 min
4Cross-site scripting and Content Security PolicyXSS lets an attacker run script as your user, which defeats CSRF tokens and steals data. Encode output by default and add a strict CSP as a second layer.4 checks · 2 min
5CSRF and cookiesCookies carry your sessions, so their flags matter. These checks stop other sites from using your users' cookies against them.3 checks · 2 min
6Security headers and configuration (A02)Security misconfiguration is number two in 2025. Headers, TLS and production settings are cheap to fix and easy to check from outside.4 checks · 2 min
7Supply chain, integrity and secrets (A03, A08)Software supply chain failures are new at number three. Your app is only as safe as the packages, build steps and keys it depends on.5 checks · 3 min
- 1Commit the lockfile and install from it in CI
- 2Scan dependencies for known vulnerabilities on every change
- 3Review new packages and install scripts before adding them
- 4Keep secrets out of the repository and the client bundle
- 5Use Subresource Integrity on scripts loaded from a CDN
5 in this chapterOpen this chapter8Logging, errors and file uploads (A09, A10)You cannot respond to an attack you never see, and an error that fails open can be worse than the bug that caused it. File uploads close the list because they mix several of these risks.5 checks · 3 min
- 1Log sign-ins, permission failures and admin actions
- 2Alert on bursts of failures and unusual admin activity
- 3Fail closed when a security check throws
- 4Return generic error messages and keep details in logs
- 5Validate uploads by allowlist, size and content, and store them safely
5 in this chapterOpen this chapter
About this checklist
This web application security checklist is what you go through before a release, or when you inherit a codebase and want to know how exposed it is. It follows the OWASP Top 10:2025, the current edition of the most widely used list of web application security risks, and borrows concrete settings from the OWASP Application Security Verification Standard (ASVS 5.0) and the OWASP Cheat Sheet Series.
The 2025 list moved things around. Broken Access Control is still number one and now includes server-side request forgery. Security Misconfiguration rose to number two. Software Supply Chain Failures is a new, wider category at number three, and Mishandling of Exceptional Conditions is new at number ten. The chapters below follow those risks, so you spend your time where real breaches happen.
Every check has a severity. A must is something an attacker can use against you today, a should closes a common gap, and a nice adds depth. Every check also says how to verify it: a request to send, a header to look for, a setting to read. Ticking a box without that evidence is how teams end up with a checklist that says secure and an app that is not.
Work through it with your app running and your browser dev tools open. Most checks take a few minutes each, and the whole list fits in an afternoon for a small app.
Common questions
What is the OWASP Top 10 2025?
It is the current edition of OWASP's list of the most critical web application security risks. Broken Access Control stays at number one, Security Misconfiguration rises to two, and two categories are new: Software Supply Chain Failures at three and Mishandling of Exceptional Conditions at ten. It is an awareness document, so use ASVS when you need testable requirements.
What is the difference between the OWASP Top 10 and ASVS?
The Top 10 is a short list of risk categories meant to raise awareness. The Application Security Verification Standard (ASVS) is a detailed set of testable requirements grouped into levels; the current version is 5.0. Teams usually start with a Top 10 checklist like this one and move to ASVS when they need a formal standard.
Is SameSite enough to prevent CSRF?
No. OWASP describes SameSite as defense in depth that does not replace a proper CSRF defense in most deployments. Lax still sends cookies on top-level GET navigations, and older browsers may not enforce it. Use your framework's CSRF protection, a token, or a Fetch Metadata check as the main defense.
How do I check my website's security headers?
Run curl -sI https://your.site and read the response headers, or open the Network tab in your browser's dev tools. Check a page, an API route and a static file, because headers often differ between them. Look for HSTS, a CSP, nosniff, Referrer-Policy and frame-ancestors.
Which password hashing algorithm should I use?
OWASP recommends Argon2id with at least 19 MiB of memory, 2 iterations and parallelism of 1. Use scrypt when Argon2id is not available, bcrypt only for legacy systems, and PBKDF2 when you need FIPS-140 compliance. Never use a fast hash like SHA-256 on its own.
Sources (8)
Checked against these, last on 12 October 2026.
- OWASP Top 10:2025, OWASPtop10.owasp.org/2025/
- OWASP Application Security Verification Standard (ASVS), OWASPowasp.org/www-project-application-security-verification-standard/
- HTTP Security Response Headers Cheat Sheet, OWASP Cheat Sheet Seriescheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html
- Content Security Policy Cheat Sheet, OWASP Cheat Sheet Seriescheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html
- Cross-Site Request Forgery Prevention Cheat Sheet, OWASP Cheat Sheet Seriescheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
- Password Storage Cheat Sheet, OWASP Cheat Sheet Seriescheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html
- File Upload Cheat Sheet, OWASP Cheat Sheet Seriescheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html
- NIST SP 800-63B-4: Digital Identity Guidelines, Authentication and Authenticator Management, NISTdoi.org/10.6028/NIST.SP.800-63B-4
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Authentication Best PracticesBuild sign-in that holds up: password rules from NIST, Argon2id hashing, login throttling, MFA and passkeys, secure sessions and safe account recovery.
- Authorization Best PracticesGet access control right: deny by default, object-level checks against IDOR, RBAC vs ABAC vs ReBAC, tenant isolation with row-level security, audits and tests.
- Browser Security Best PracticesSecure the front end and HTTP layer: XSS and Trusted Types, Content Security Policy, CORS, cookies, CSRF, framing, security headers, third-party scripts and postMessage.
Checklists
See all- API Security ChecklistCheck your REST or GraphQL API against the OWASP API Security Top 10: authentication, object authorization, rate limits, input validation, SSRF, CORS and logging.
- Linux Server Hardening ChecklistHarden an Ubuntu, Debian or RHEL server step by step: accounts and sudo, SSH, updates, firewall and open ports, permissions, logging and CIS benchmark scans.
- Software Supply Chain Security ChecklistCheck your dependencies and builds before a release: lockfiles, update bots, pinned actions, CI permissions, SLSA provenance, Sigstore signing, SBOMs and a plan for a compromised package.
Project structures
See all- Firebase (Cloud Functions and security rules) project structureFor students building an app on Firebase who need a real backend: Cloud Functions (2nd gen) in TypeScript, Firestore and Storage security rules with tests, and the Local Emulator Suite. The tree starts from
firebase initand grows into feature folders of callables, triggers and scheduled jobs, then adds CI deploys, environments, contract tests and runbooks. - AI agent with an MCP server project structureFor developers who want to give AI assistants safe access to their own data or API. A TypeScript MCP server built on the official SDK, organised by feature (tasks, projects) with each feature owning its tools, resources and prompts, served over stdio for local hosts and Streamable HTTP with OAuth for remote ones, plus a small agent and the evals that prove a model can use it.
- Terraform project structureAn infrastructure repository for a small app on AWS: reusable modules, one folder per environment with its own remote state, pinned providers, tests and security scans, with plan on every pull request and apply from CI. For students who have finished the Terraform tutorials and want to know how a real team lays out the files. The same layout works unchanged with OpenTofu.
Career questions
See all- How do I get into AI security as a student or junior engineer?Build a normal security or software foundation first, then learn how LLM apps fail using the OWASP Top 10 for LLM Applications and MITRE ATLAS, and prove it by building, testing and hardening a small LLM app of your own. Most people reach AI security through AppSec, security engineering or ML engineering, not straight from university.
- Where do I start if I want a career in cybersecurity or IT operations?Start with the foundations both fields share: networking, Linux, and how systems fail. Then choose an entry role such as SOC analyst, IT support or junior cloud operations, and prove it with hands-on labs and one documented project rather than a stack of certificates.
- Can I use AI coding tools at my internship, and what should I never paste into them?Usually yes, but only the tools your company has approved, on the code and data they allow, and in the way they allow. Ask in your first week. Never paste secrets, customer data or code you are not permitted to share, and review everything the tool writes as if your name is on it, because it is.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com