OWASP — the Open Web Application Security Project — publishes a list of the ten most critical security risks in web applications. It's updated every few years based on real incident data. If your software has any of these vulnerabilities, you're one incident away from a breach that damages your business and your clients' trust.
This guide explains each risk in plain English and gives you the questions to ask your development team about each one.
1. Broken Access Control
What it means: Users can access data or perform actions they shouldn't be allowed to.
Example: A user changes the URL from /invoice/1234 to /invoice/1235 and sees someone else's invoice.
The damage: Data exposure, regulatory violation (GDPR, HIPAA), loss of client trust.
Ask your team: "Have you tested whether a logged-in user can access another user's data by changing IDs in the URL or API requests?"
2. Cryptographic Failures
What it means: Sensitive data is transmitted or stored without adequate encryption.
Example: Passwords stored as plain text. Credit card numbers transmitted over HTTP instead of HTTPS. Session tokens that can be decoded.
The damage: Any breach exposes all user credentials. One database dump affects every user.
Ask your team: "How are passwords stored? Are we using HTTPS everywhere? What data is encrypted at rest?"
3. Injection
What it means: Untrusted data is sent to an interpreter (database, shell, LDAP) as part of a command, allowing an attacker to change the command's intent.
Example: SQL injection — an attacker enters "' OR '1'='1" into a login field and bypasses authentication entirely.
The damage: Full database access, authentication bypass, data deletion.
Ask your team: "Do we use parameterised queries or an ORM everywhere we interact with the database? Have we run any injection tests?"
4. Insecure Design
What it means: Security wasn't considered during design — the architecture itself enables attacks.
Example: A password reset flow that lets attackers enumerate which email addresses are registered. A rate-limit-free login form that allows unlimited password guessing.
The damage: Structural vulnerabilities that can't be patched without redesign.
Ask your team: "At what point in the design process do we think about security? Can you walk me through the authentication and password reset flows?"
5. Security Misconfiguration
What it means: Servers, databases, and cloud services left with default or insecure settings.
Example: An S3 bucket set to public. A database with no password. A server with directory listing enabled. An admin interface exposed to the public internet.
The damage: Often catastrophic — misconfigured cloud storage is the source of many of the largest data breaches.
Ask your team: "Are there any services running in production with default credentials? Is our cloud infrastructure reviewed against a security baseline?"
6. Vulnerable and Outdated Components
What it means: Using libraries or frameworks with known security vulnerabilities.
Example: Running an old version of a Node.js package that has a published CVE (Common Vulnerabilities and Exposures).
The damage: Known attacks against known vulnerabilities — often automated and opportunistic.
Ask your team: "How do we track dependency vulnerabilities? Do we have automated dependency updates or alerts?"
7. Identification and Authentication Failures
What it means: Weak implementation of login, session management, or identity verification.
Example: Sessions that don't expire. No account lockout after failed login attempts. Passwords with no complexity requirements. No multi-factor authentication on admin accounts.
The damage: Account takeover, credential stuffing, unauthorised access.
Ask your team: "Do sessions expire? Are there brute-force protections on login? Is MFA available on admin accounts?"
8. Software and Data Integrity Failures
What it means: Code or data updates are applied without verifying they haven't been tampered with.
Example: Loading JavaScript from a third-party CDN without a cryptographic checksum (subresource integrity check). An auto-update mechanism that doesn't verify the source.
The damage: Supply chain attacks — malicious code executed in your application.
Ask your team: "Do we use subresource integrity on any third-party scripts? How do we verify the integrity of packages we install?"
9. Security Logging and Monitoring Failures
What it means: Security events aren't logged, or logs aren't monitored for anomalies.
Example: Failed login attempts aren't logged. There's no alert when 1,000 requests hit the API in one minute. A breach goes undetected for months.
The damage: Breaches go undetected. When detected, you can't reconstruct what happened.
Ask your team: "What events do we log? Are we alerted when something anomalous happens? How would we know if we'd been breached?"
10. Server-Side Request Forgery (SSRF)
What it means: An attacker tricks the server into making HTTP requests to internal services.
Example: The attacker provides a URL that points to an internal AWS metadata endpoint, retrieving cloud credentials.
The damage: Access to internal services, cloud credentials, and data that should never be reachable from the internet.
Ask your team: "Do we validate or restrict URLs that users can submit for the server to fetch? Do we use allow-lists for any external URL fetching?"
What to Do with This Information
You don't need to understand the technical implementation of each fix. What you need to do is:
1. Ask your team which of these they've explicitly addressed 2. Ask for evidence — tests, code review practices, tool reports 3. For any that haven't been addressed, ask for a timeline
A development team that takes security seriously will have clear answers. A team that deflects or treats these as theoretical concerns is telling you something important about how they've been building.
At SoftGodam, every project goes through an OWASP Top 10 review before go-live. It's not optional — it's in our delivery checklist.