- 22
- February
If you have ever heard the phrase "the system passed OWASP" or "tested against the OWASP Top 10 standard" and wondered what it means, how it is tested, and how you can tell whether your system truly passes — this article explains everything in plain language, complete with a testing tools comparison table and criteria that every Thai organization should know.
What Is OWASP?
OWASP (Open Worldwide Application Security Project) is a global non-profit organization founded in 2001 with the goal of improving software security worldwide. It produces guidelines, tools, and reference documents that are freely available to everyone.
OWASP Top 10 is a list of the 10 most common web application security risks — updated every 3-4 years, with the latest version being OWASP Top 10:2021.
Why Is the OWASP Top 10 Important?
- It is a reference standard recognized by regulators worldwide (including Thailand's ETDA and OCSC)
- It forms the foundation of every Penetration Testing and Security Audit project
- It covers vulnerabilities responsible for over 90% of hacking incidents
- Thai government agencies and private enterprises increasingly require software vendors to pass OWASP Top 10 testing before project acceptance
OWASP Top 10:2021 — What Are All 10 Categories?
Let us walk through each one with easy-to-understand examples:
A01:2021 — Broken Access Control
Users can access data or perform actions they are not authorized to. For example, a regular employee viewing executive salary data or modifying records that do not belong to them.
Example: Changing the URL from /user/profile?id=100 to ?id=101 and seeing another person's data.
A02:2021 — Cryptographic Failures
The system does not encrypt sensitive data or uses outdated encryption methods. For example, storing passwords in plain text, transmitting data over HTTP instead of HTTPS, or using algorithms that have already been cracked.
A03:2021 — Injection
An attacker injects malicious commands into input fields that the system processes directly. This covers SQL Injection, XSS (Cross-Site Scripting), Command Injection, and LDAP Injection.
A04:2021 — Insecure Design
Problems arising from system architecture that was not designed with security in mind from the start — different from implementation bugs because even if the code is 100% correct, a flawed design is still insecure.
Example: A password reset system sends a link via email but has no expiration — the link works forever.
A05:2021 — Security Misconfiguration
The system is configured insecurely. For example, directory listing is enabled, default passwords are used, debug mode is on in production, or error messages reveal internal system information.
A06:2021 — Vulnerable and Outdated Components
Using libraries, frameworks, or plugins with known vulnerabilities or outdated versions that are no longer supported — a favorite attack vector because ready-made exploits are available.
A07:2021 — Identification and Authentication Failures
The login system has weaknesses such as allowing weak passwords, no rate limiting (unlimited brute force attempts), no support for Two-Factor Authentication (2FA), or sessions that never expire.
A08:2021 — Software and Data Integrity Failures
The system does not verify the integrity of software updates, CI/CD pipelines, or data from external APIs — attackers may inject malicious code into the supply chain.
A09:2021 — Security Logging and Monitoring Failures
Insufficient logging or no alerting system — when an attack occurs, it goes undetected, cannot be investigated after the fact, and cannot be responded to in a timely manner.
A10:2021 — Server-Side Request Forgery (SSRF)
An attacker tricks the server into making requests to internal URLs that are normally inaccessible from outside, such as internal APIs, cloud metadata servers (AWS/GCP), or unexposed internal services.
OWASP Top 10 Summary Table
| Code | Name | Brief Description |
|---|---|---|
| A01 | Broken Access Control | Accessing unauthorized data or functions |
| A02 | Cryptographic Failures | Incorrect or missing encryption |
| A03 | Injection | Injecting malicious commands (SQL, XSS) |
| A04 | Insecure Design | System designed without security from the start |
| A05 | Security Misconfiguration | Incorrect or insecure system configuration |
| A06 | Vulnerable Components | Using libraries/frameworks with known vulnerabilities |
| A07 | Auth Failures | Weaknesses in the authentication system |
| A08 | Integrity Failures | No verification of software/data integrity |
| A09 | Logging Failures | Insufficient logging or monitoring |
| A10 | SSRF | Tricking the server into calling internal URLs |
How to Test for OWASP Top 10?
There are two main testing approaches that must be used together — no single tool can cover everything:
1. Automated Testing
Use tools to automatically scan for vulnerabilities — ideal for initial assessments and regular recurring checks.
| Tool | Type | Price | OWASP Coverage |
|---|---|---|---|
| OWASP ZAP | DAST (Dynamic) | Free (Open Source) | A01, A03, A05, A07 |
| Burp Suite | DAST + Manual | Community Free / Pro Paid | A01-A10 (Pro) |
| Nikto | Web Server Scanner | Free (Open Source) | A05, A06 |
| SonarQube | SAST (Static) | Community Free / Enterprise Paid | A03, A04, A08 |
| OWASP Dependency-Check | SCA (Software Composition) | Free (Open Source) | A06 |
| Nessus | Vulnerability Scanner | Paid (Trial Available) | A02, A05, A06 |
Recommended for Getting Started:
Use OWASP ZAP (free) to perform initial web application scanning + OWASP Dependency-Check to check for vulnerable libraries — these two tools cover the most common issues at no cost.
2. Manual Testing (Penetration Testing)
Use security experts (pentesters) to test manually — because some types of vulnerabilities cannot be detected by automated tools:
| OWASP Vulnerability | Manual Testing Method |
|---|---|
| A01 Broken Access Control | Change IDs in URLs, try accessing other users' APIs, test role escalation |
| A02 Cryptographic Failures | Check HTTPS certificates, inspect HTTP headers, verify password storage methods |
| A03 Injection | Submit SQL payloads in input fields, test for XSS across various inputs |
| A04 Insecure Design | Review architecture, check for business logic flaws, perform threat modeling |
| A05 Security Misconfig | Check default credentials, HTTP headers, error messages, open ports |
| A06 Vulnerable Components | Check all library versions against the CVE database |
| A07 Auth Failures | Brute force testing, session hijacking, password policy testing |
| A08 Integrity Failures | Inspect CI/CD pipeline, deserialization testing, SRI checks |
| A09 Logging Failures | Verify whether failed logins and anomalies are logged, check if alerts exist |
| A10 SSRF | Test sending internal URLs (127.0.0.1, metadata endpoints) through inputs |
3. Code Review
Review the source code directly to find hidden vulnerabilities — the best method for A04 (Insecure Design) and A08 (Integrity Failures), which external scanning tools cannot detect.
How Do You Know If You "Pass" the OWASP Top 10?
The phrase "passed OWASP" does not come with an official certificate from OWASP — but there are clear criteria and standards used to measure results:
Criterion 1: Penetration Test Report
When you hire a security firm to conduct a pentest, you receive a report that classifies vulnerabilities by severity level:
| Severity Level | Meaning | Passing Criteria |
|---|---|---|
| Critical | Severe vulnerability, exploitable immediately | Must have zero |
| High | Significant vulnerability, high risk | Must have zero |
| Medium | Moderate vulnerability | Must have a remediation plan |
| Low | Low-level vulnerability | Acknowledge and monitor |
| Informational | Observations/recommendations | Consider improving |
Summary: "Passing" the OWASP Top 10 means
- No Critical or High severity vulnerabilities
- Medium severity vulnerabilities have a remediation plan within a defined timeframe
- Testing covers all 10 categories (not just some)
Criterion 2: OWASP ASVS Standard
ASVS (Application Security Verification Standard) is a standard created by OWASP to systematically verify application security. It has 3 levels:
| Level | Suitable For | Number of Requirements |
|---|---|---|
| Level 1 | General applications — low risk | ~130 requirements |
| Level 2 | Applications with sensitive data, e.g. ERP systems | ~270 requirements |
| Level 3 | Highest-risk applications, e.g. banking, healthcare, military | ~290 requirements |
Criterion 3: Related International Standards
- ISO 27001 — Information security management system (ISMS) standard covering policies, people, and technology
- PCI DSS — Standard for payment-related systems that requires OWASP Top 10 testing
- PDPA (Personal Data Protection Act) — Thai law requiring appropriate security measures for personal data
Complete OWASP Top 10 Testing Process
For organizations that need to test their ERP system or web application, here is the recommended process:
| Step | Details | Responsible Party |
|---|---|---|
| 1. Define Scope | Identify URLs, API endpoints, and systems to test | Project Manager + Pentester |
| 2. Automated Scan | Use OWASP ZAP / Burp Suite for initial scanning | Security Team / Pentester |
| 3. Manual Pentest | Manual testing covering A01-A10 | Pentester (Specialist) |
| 4. Code Review | Review source code at high-risk points | Security Engineer / Developer |
| 5. Report | Summarize vulnerabilities + severity levels + recommendations | Pentester |
| 6. Remediation | Fix vulnerabilities according to recommendations | Development Team |
| 7. Re-test | Re-test only the fixed vulnerabilities to confirm successful remediation | Pentester |
Saeree ERP and the OWASP Top 10
Saeree ERP was designed with OWASP Top 10 security in mind from the architecture level:
| OWASP | Saeree ERP Approach |
|---|---|
| A01 Access Control | Role-Based Access Control (RBAC) with permissions down to menu and button level |
| A02 Cryptographic | HTTPS for all connections, BCrypt password hashing, encryption of sensitive data |
| A03 Injection | ORM + Parameterized Query at every point, no SQL string concatenation |
| A04 Insecure Design | Layered Architecture with clear separation (API > Service > Data) |
| A05 Misconfiguration | Security Hardening Checklist, debug disabled in production, custom error pages |
| A06 Vulnerable Components | Regular framework/library updates, CVE checks before deployment |
| A07 Auth Failures | Support for Two-Factor Authentication (2FA), password policy, session timeout |
| A08 Integrity | Checksum verification for updates, digital signature for documents |
| A09 Logging | Audit trail for every transaction, logging of all successful/failed logins |
| A10 SSRF | URL whitelist for allowed destinations, internal IP requests from user input blocked |
Passing the OWASP Top 10 is not just about tools or a one-time test — it is about designing your system to be secure from the ground up and testing it regularly. Saeree ERP was built on the principle of "Security by Design" so organizations can be confident their critical data is properly protected.
- Saeree ERP Development Team
Checklist for Organizations — Is Your System Ready to Handle the OWASP Top 10?
| ☐ | Has penetration testing been conducted covering all 10 OWASP Top 10 categories? |
| ☐ | Does the pentest report show zero Critical/High severity vulnerabilities? |
| ☐ | Is there an access control system with granular permissions down to menu/button level? |
| ☐ | Do all SQL queries use Parameterized Query / ORM? |
| ☐ | Is sensitive data (passwords, personal information) encrypted? |
| ☐ | Does the system support Two-Factor Authentication (2FA)? |
| ☐ | Is there an audit trail recording every change? |
| ☐ | Are all libraries/frameworks up to date with no known CVEs? |
| ☐ | Is there a regular re-testing plan (at least once per year)? |
If your organization needs an ERP system designed according to OWASP Top 10 principles from the architecture level, you can schedule a demo or contact our consulting team to learn more.
