Web and API
Website security check and API 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's URL scan checks what anyone can see from the internet, and KROMSE checks the code, dependencies and container images behind the site. It does not run full dynamic application testing (DAST) or penetration tests.
- 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.
- URL scan: HTTPS, security headers, cookies, outdated scripts and exposed files, as anyone on the internet sees them.
Frequently asked questions
Does KROMSE test websites and APIs?
Partly. The URL scan checks what anyone can see from the internet (HTTPS, security headers, cookies, outdated scripts, exposed files). KROMSE does not run full dynamic application testing (DAST) or penetration tests. It also checks the code, dependencies and container images behind the site.
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.