OWASP - the foundation of every line of code we write
No more insecure software.
The vision of the OWASP project
OWASP in brief
An open community against insecure software
OWASP stands for the Open Worldwide Application Security Project, an open, non-profit community of specialists working worldwide towards a single goal: software should no longer be insecure.
Its best-known result is the OWASP Top 10: a list of the ten most critical security risks for web applications. OWASP itself calls it a Standard Awareness Document, shared ground for everyone who builds applications. Around the world it is seen as the first step towards more secure code.
Everything is freely available, open for anyone to inspect, and updated continuously. No vendor, no license, no black box. You do not have to take our word for it, you can read it yourself.
Four things OWASP and we have in common
- Open Source
Open standards, reviewed in the open. What thousands of specialists read over holds up longer than any secret recipe.
- Security
Security is not optional for us. OWASP names the risks we want to rule out in every project, before somebody else finds them.
- Transparency
You can look up what we test against. A public benchmark instead of a security promise that nobody can check.
- Clean Code
Security happens in the line of code, not afterwards. OWASP turns good intentions into a routine that can be verified.
From idea to operation
Where OWASP shows up in our process
Why your project benefits from OWASP
- Less risk
Attackers rarely improvise. They work through lists, automated, from your first day live. Close the known routes and you drop out of the cheap mass sweep. What is left is effort, and few attackers bother.
- Predictable costs
A weakness in the design costs a conversation. The same weakness after go-live costs a hotfix, an unplanned release and, quite possibly, a notice to your customers. The difference is not technical, it is a matter of timing.
- Verifiable, not just claimed
Sooner or later the question comes from outside: your insurer, a tender form, the security team at your biggest customer. OWASP is known there. You will not have to explain who we are, or why you took our word for it.
- A path to certification
OWASP is not a seal, but the step before one. If your project is to become a certified product later on, you are not starting from zero. Up to and including Common Criteria.
The toolbox
Six projects and what we do with them
- OWASP Top 10
- The ten most critical risks for web applications, surveyed afresh every three to four years. OWASP calls it a Standard Awareness Document. Shared ground, and explicitly not a test plan.How we use it: The benchmark in design and code review. Every one of the ten categories is weighed against your project instead of ticked off wholesale.
- Web Security Testing Guide
- A handbook for testing applications systematically for vulnerabilities. The related Application Security Verification Standard sets out, in levels, what an application has to be capable of.How we use it: The basis of our test cases. "We tested it" becomes a list that shows what was checked and what was not.
- Dependency-Track
- Continuously checks an application's libraries against known vulnerabilities, including the dependencies nobody added on purpose.How we use it: Runs in production against the Software Bill of Materials of our projects. If a component turns vulnerable overnight, we know before you do.
- ModSecurity
- An open web application firewall. Filters out known attack patterns before they reach the application.How we use it: In production use, with the OWASP Core Rule Set. It does not replace a secure application. It buys the time between a known gap and a shipped patch.
- Application Security
- Not a single project, but the frame around them: security as a property of the application, not a product you stand next to it.How we use it: The stance the other five follow from. With us, security belongs in the architecture, not in the sign-off.
- Mobile Application Security
- Its own standards and a testing guide for apps, from storage on the device to the interface behind it.How we use it: On the server our rules apply. On your users' devices they do not. So in app projects we ask the uncomfortable question first: what does the app really need to store locally and what happens to it once the device itself can no longer be trusted?
The technical details
From here on it gets technical
From here on, things get a little more technical. We’ll explain the risks described in the OWASP Top 10, how they arise in real-world applications, and what we specifically look for during a security audit. The following explanations will also help you better understand these risks, grasp the technical measures involved, and ask the right questions of development teams or service providers.
As of: OWASP Top 10:2025. The list is revised every three to four years. In case of doubt, the source applies.
A01
Broken Access Control
Users see or do more than intended: missing authorization checks, insecure direct object references, privilege escalation. Since 2025, server-side request forgery belongs here as well.
A02
Security Misconfiguration
Built right, wired wrong. Default accounts, exposed admin interfaces, missing security headers, overly generous permissions in the cloud.
A03
Software Supply Chain Failures
New. Not just the vulnerable library, but the entire supply chain: compromised build systems, tampered artifacts, transitive dependencies nobody can trace back any more.
A04
Cryptographic Failures
Missing or weak protection of data in transit and at rest: outdated methods, poor key management, encryption in the wrong place.
A05
Injection
Unvalidated input ends up where it gets interpreted. In the database, in the shell, in the template engine.
A06
Insecure Design
The flaw is not in the code, it is in the design. No code review in the world repairs a concept that never allowed for misuse.
A07
Authentication Failures
Sign-in and session management: weak password rules, recovery paths open to attack, sessions that live longer than the user needs them.
A08
Software or Data Integrity Failures
Updates, pipelines and data without an integrity check. Anyone who does not sign their artifacts is trusting to good weather.
A09
Security Logging and Alerting Failures
An attack nobody notices carries on. Without logging and alerting there is neither a response nor any forensics.
A10
Mishandling of Exceptional Conditions
New. Error handling that opens rather than closes when in doubt: swallowed exceptions, half-finished recovery, error messages that give away too much.
Ready to take the next step?
Would you like to know how secure your application really is, or how OWASP can be effectively integrated into your project? We’ll take a look at your architecture, code, and processes, in a clear, pragmatic way, without any security theatrics.
Oliver Schweissgut
Shareholder and CEO
Christian Seewald
Chief Executive Officer