OWASP (the Open Worldwide Application Security Project) is a non-profit that publishes free, vendor-neutral guidance for building secure web applications. The best-known piece is the OWASP Top 10, a list of the most serious risk categories, but using OWASP well means more than reading that list: you pick a verification standard, check your code against it, and test it with automated tools. This page gives you that workflow in short form.
Use the OWASP Top 10 to decide what to fix first, the OWASP ASVS as your checklist of concrete requirements, the OWASP Cheat Sheet Series for how to implement each control, and a scanner such as ZAP plus a dependency checker to test the result. Build these checks into development rather than running them once before launch.
Our detailed article, OWASP Top 10: what actually breaks Indian web apps, goes through each category with PHP and Node.js defences. This page is the short workflow; read that one when you are fixing code.
1. The OWASP resources you will actually use
| Resource | What it is | When to use it |
|---|---|---|
| OWASP Top 10 | The ten most critical web application risk categories | Awareness, and deciding what to fix first |
| ASVS (Application Security Verification Standard) | A detailed list of testable security requirements, in three levels | As the checklist for design, code review and testing |
| Cheat Sheet Series | Short, practical guides per topic (passwords, sessions, file upload, headers) | While writing the code for a specific control |
| Dependency-Check | Scans your project's libraries for known vulnerabilities | In every build, and before each release |
| Secure Headers Project | Recommended HTTP security headers and values | When configuring your web server or framework |
ZAP, the free web application scanner that used to be called OWASP ZAP, is no longer an OWASP project, but it is still free, open source and the usual choice for scanning a running site.
2. The current Top 10 at a glance
The current edition is the OWASP Top 10:2025, which replaced the 2021 list. Most older articles, including parts of our own guides, still use the 2021 numbering, so here are both.
| 2025 category | Closest 2021 category | In one line |
|---|---|---|
| A01 Broken Access Control | A01 (now also includes SSRF, 2021 A10) | Users can read or change data that is not theirs |
| A02 Security Misconfiguration | A05 | Default settings, verbose errors, exposed files |
| A03 Software Supply Chain Failures | A06 Vulnerable and Outdated Components | Outdated or compromised libraries, plugins and build tools |
| A04 Cryptographic Failures | A02 | Plain HTTP, weak hashing, secrets in code |
| A05 Injection | A03 | SQL, command and script injection, including XSS |
| A06 Insecure Design | A04 | Missing rate limits and unsafe business logic |
| A07 Authentication Failures | A07 | Weak passwords, no MFA, poor session handling |
| A08 Software or Data Integrity Failures | A08 | Unsigned updates, untrusted deserialisation |
| A09 Security Logging and Alerting Failures | A09 | Attacks nobody notices |
| A10 Mishandling of Exceptional Conditions | New | Errors that fail open or leak details |
3. A workflow for applying the guidelines
- Pick an ASVS level.Level 1 is the minimum for any public site. Choose Level 2 for anything with logins, payments or personal data.
- Threat-model the design.Before coding a feature, ask who could misuse it and how. This is where insecure design (A06) is prevented.
- Implement with the cheat sheets.Use parameterised queries, output encoding, bcrypt or Argon2id for passwords, httpOnly and Secure cookies, and server-side access checks on every request.
- Check dependencies on every build.Run your ecosystem's audit (
npm audit,composer audit) or OWASP Dependency-Check, and update before you release. - Scan the running app.Run a ZAP baseline scan against a staging copy, never against someone else's site.
- Log and alert.Record logins, failed logins, permission failures and admin actions, and make sure someone is told when they spike.
4. Running this on Domain India
Our cPanel and DirectAdmin shared servers run Imunify360 and a CSF firewall, and the cPanel servers also run a ModSecurity web application firewall with Imunify360's rule set. These catch many automated attacks, but they do not fix vulnerable code, so the workflow above still applies. For the steps to take if a site is compromised, see the security checklist for a hacked website.
Related guides: preventing SQL injection, preventing XSS, password hashing with bcrypt and Argon2 and security headers explained.
What is the OWASP Top 10?
It is a list of the ten most critical security risk categories for web applications, published by the non-profit OWASP. The current edition is the Top 10:2025, which replaced the 2021 list. It is an awareness document, not a complete checklist.
What is the difference between the OWASP Top 10 and the ASVS?
The Top 10 names broad risk categories. The ASVS (Application Security Verification Standard) lists specific, testable requirements in three levels, so it is the better document to use as a development and testing checklist.
Is ZAP still an OWASP tool?
No. ZAP, formerly OWASP ZAP, left OWASP in 2023. It is still free and open source, and it is still widely used to scan running web applications for vulnerabilities.
Does a web application firewall make my code secure?
No. A firewall such as ModSecurity blocks many known attack patterns, but it cannot fix broken access control, weak passwords or unsafe business logic in your application. Treat it as an extra layer, not a replacement for secure code.
Ready to harden your application? Work through the full OWASP Top 10 guide, and if something on your hosting account looks wrong, open a support ticket.
Tell us your domain and what you are seeing, and our support team will check the server side with you.
Open a ticket