Web and API
Website and API security testing: DAST explained
Website and API security testing, often called dynamic application security testing (DAST), sends crafted requests to a running application and observes how it responds, to find flaws such as broken access control, injection and misconfiguration. It complements code and dependency scanning, and it must only be run against systems you own or are authorised in writing to test.
Free plan, no card required.
What is dynamic application security testing (DAST)?
Dynamic testing treats the application as a black box, or a grey box when the tester has credentials. A tool or a person crawls the site or reads the API description, then sends requests designed to provoke failures: modified identifiers, unexpected parameters, oversized payloads, missing or forged tokens. Findings come from behaviour, not source code. That is both the strength and the limit of the method: it sees what an attacker sees, including deployment and configuration problems, but it only finds what it manages to reach.
For APIs, coverage depends on knowing the endpoints. An OpenAPI description, a Postman collection or recorded traffic lets a test reach operations a crawler would never find. Authenticated testing with at least two accounts in different roles is what reveals the flaw at the top of the OWASP API Security Top 10: one user reaching another user's objects.
How does DAST differ from SAST and dependency scanning?
The three methods answer different questions. Dependency scanning tells you whether the components you ship are known to be vulnerable. Static analysis tells you whether your own code contains dangerous patterns. Dynamic testing tells you whether the deployed system, with its configuration, authentication and infrastructure, can actually be abused. A mature programme uses all three and uses dynamic results to confirm which static and dependency findings are exploitable in practice.
| Method | What it examines | Typical findings | Blind spots |
|---|---|---|---|
| Dependency scanning | Lockfiles, manifests, SBOMs and container images | Known vulnerabilities and malicious packages in third-party components | Flaws in your own code and in how the application is deployed |
| Static analysis (SAST) | Your source code, without running it | Injection patterns, unsafe functions, hard-coded credentials | Runtime configuration and authorisation logic spread across services |
| Dynamic testing (DAST) | The running website or API, over the network | Broken access control, injection, misconfiguration, exposed endpoints | Code paths the test cannot reach, and the root cause in the code |
Why limit testing to domains you own or are authorised to test?
A security test and an attack look the same on the wire; the difference is permission. In the EU, Directive 2013/40/EU requires Member States to criminalise, at least in cases that are not minor, illegal access to information systems and illegal system interference committed intentionally and “without right”. The Directive defines that as conduct not authorised by the owner or another right holder of the system, or not permitted under national law. National laws differ in detail, but the working rule is the same everywhere: no written authorisation, no test.
Authorisation has technical edges too. A site behind shared hosting, a content delivery network or a third-party API gateway involves other owners whose terms may restrict testing, and a test that overloads a shared service can harm other customers. Proving control of a domain, for example with a DNS record or a file on the web server, is a common way for a testing service to confirm that the requester is entitled to test it. Keep the authorisation, scope, test window and contact person on record with the results.
Which OWASP lists should website and API tests cover?
The OWASP Top 10 and the OWASP API Security Top 10 are the usual reference points for scoping a test. They are awareness documents rather than complete test standards, but they name the classes of flaw that matter most. The current editions are the OWASP Top 10:2025 for web applications and the OWASP API Security Top 10 2023 for APIs.
Several categories are not found by dynamic testing alone. Software supply chain failures are largely a question of dependencies and builds, and improper inventory management starts with knowing which API versions and hosts you run. That is where code-side scanning and an accurate inventory fill the gap.
| Rank | OWASP Top 10:2025 | OWASP API Security Top 10 2023 |
|---|---|---|
| 1 | Broken Access Control | Broken Object Level Authorization |
| 2 | Security Misconfiguration | Broken Authentication |
| 3 | Software Supply Chain Failures | Broken Object Property Level Authorization |
| 4 | Cryptographic Failures | Unrestricted Resource Consumption |
| 5 | Injection | Broken Function Level Authorization |
| 6 | Insecure Design | Unrestricted Access to Sensitive Business Flows |
| 7 | Authentication Failures | Server Side Request Forgery |
| 8 | Software or Data Integrity Failures | Security Misconfiguration |
| 9 | Security Logging and Alerting Failures | Improper Inventory Management |
| 10 | Mishandling of Exceptional Conditions | Unsafe Consumption of APIs |
How does web and API testing fit the CRA and NIS2?
Under the CRA, a product with digital elements includes its remote data processing solutions: processing at a distance, designed and developed by or under the responsibility of the manufacturer, without which the product could not perform one of its functions. The CRA's recitals give the example of a mobile app that needs an API provided by the manufacturer; that API is in scope, while websites that do not support a product's functionality are not. Annex I Part II requires effective and regular tests and reviews of the product's security, which for a product with a cloud backend can reasonably include testing its API.
Software offered purely as a service falls outside the CRA; the CRA's recitals point to NIS2 for cloud computing services such as software as a service. NIS2 Article 21(2)(e) asks essential and important entities for security in the acquisition, development and maintenance of their systems, including vulnerability handling and disclosure. For certain digital service providers, Implementing Regulation (EU) 2024/2690 adds a documented security-testing policy, tests whose need, scope, frequency and type follow from the risk assessment, and records of each test's type, scope, time and results.
Available in KROMSE today
KROMSE does not test running websites or APIs yet, but it checks the code, dependencies and container images behind them.
- Dependency checks against OSV.dev for the lockfiles and manifests behind your site or API, including npm, Yarn, pnpm, Poetry, uv, pip, Go, Cargo, Maven, Gradle, Composer, Bundler and .NET.
- Source code analysis for 11 languages, including JavaScript, TypeScript, Python, Java, Go and C#, plus import of your own SARIF 2.1.0 results.
- Secret detection at the scanned commit; secret values are redacted and never stored.
- Misconfiguration checks for Terraform and Dockerfiles.
- Container images in a registry reachable from the internet, analysed for vulnerabilities, misconfigurations and secrets.
- Packages listed in the OpenSSF Malicious Packages database are flagged as critical, with removal as the remediation.
Coming next
On the roadmap, not available yet. Dates are targets, not promises; this page changes the day a capability is live.
- Coming · Q4 2026 (December)Website and API testing. KROMSE will test websites and APIs for vulnerabilities, only on domains you have verified you control.
- Coming · Q4 2026 (December)Monitoring on your schedule, with AI agents. Rescans will run on a schedule you set, with AI agents that watch for new advisories, triage what applies, propose fixes and draft the report for your review.
Frequently asked questions
Does KROMSE test websites and APIs?
Not yet. KROMSE does not run dynamic tests against websites or APIs today. It checks what sits behind them: dependencies, source code in 11 languages, committed secrets, Terraform and Dockerfile misconfigurations, and container images. Security testing of websites and APIs on domains you have verified you control is on the roadmap, and this page will change when it is available.
Is it legal to scan a website I do not own?
As a rule, not without permission. Directive 2013/40/EU requires EU Member States to criminalise illegal access to and interference with information systems committed intentionally and without right, meaning without authorisation from the owner or another right holder, at least where cases are not minor. National laws add their own rules. Only test systems you own or have written authorisation to test, and respect the terms of any hosting, CDN or API provider involved.
What is the difference between DAST and penetration testing?
DAST is usually automated: a tool sends many requests and reports behaviour that matches known flaw patterns. A penetration test is led by a person who chains findings, tests business logic and judges impact, often using DAST tools along the way. Automated testing suits frequent, repeatable checks; a penetration test suits major releases, significant changes and high-risk systems.
Does the CRA require security testing of my product's API?
The CRA does not prescribe a test method. Annex I Part II requires effective and regular tests and reviews of the product's security, and a product includes its remote data processing solutions, such as an API your app cannot work without. Choose the methods your risk assessment justifies, and keep the test scope, method and results in your technical documentation.
Which OWASP list should I use for APIs?
Use the OWASP API Security Top 10, whose current edition is from 2023. It focuses on API-specific flaws such as Broken Object Level Authorization, Broken Authentication, Unrestricted Resource Consumption and Improper Inventory Management, which web-oriented lists cover less directly. Use it alongside the OWASP Top 10:2025 for the web front end.