DAST & API Security
Web application penetration testing checklist
A penetration test is a controlled, authorised attack on your own application, carried out to find out what a real attacker could do. This checklist follows a web application penetration test from start to finish: 14 phases and 91 checks, from the ...
What is DAST (dynamic application security testing)?
Dynamic application security testing (DAST) tests a running web application or API from the outside, the way an attacker would. It sends real requests, observes the responses, and reports the vulnerabilities it can prove. Because DAST needs no access ...
DAST vs SAST vs penetration testing: which do you need?
Three approaches dominate application security testing: static analysis (SAST), dynamic testing (DAST) and manual penetration testing. They find different problems, and most teams need more than one. How it works SAST reads source code and flags ...
Authenticated scanning: why you must scan behind the login
Most of an application's functionality, and most of its risk, sits behind the login page. A scanner that cannot log in only tests the public surface and misses account pages, admin areas and most APIs. How it works For an authenticated scan, the ...
Scanning single-page applications (React, Angular, Vue)
Single-page applications (SPAs) built with React, Angular or Vue load one page and then build everything else with JavaScript and background API calls. Traditional crawlers that follow HTML links see almost nothing. How it works In an SPA, navigation ...
Using browser recordings to test deep workflows
Some of the most sensitive parts of an application, such as checkout, onboarding, multi-step forms and approval flows, are hard for a crawler to reach. Recording the journey once in a browser lets a scanner replay and test it every time. How it works ...
How to security-test a REST API from OpenAPI or Postman
APIs carry most of the data in modern applications, and attackers target them directly. The fastest way to test an API thoroughly is to start from the definition or collection your team already has. How it works An OpenAPI (Swagger) file, a Postman ...
The OWASP API Security Top 10, explained
The OWASP API Security Top 10 lists the most critical risks specific to APIs. It differs from the classic OWASP Top 10 because APIs fail in their own ways, especially around authorization and data exposure. How it works The list covers broken ...
Shadow APIs and API inventory: find what you forgot
Old API versions, test endpoints and undocumented routes stay online long after teams stop thinking about them. These "shadow" and "zombie" APIs are rarely patched or monitored, which makes them attractive to attackers. How it works A new API version ...
Testing APIs for mass assignment
Mass assignment happens when an API automatically copies every field in a request into an internal object. An attacker adds fields they should not control, such as "role": "admin" or "price": 0, and the API saves them. How it works Frameworks make it ...
GraphQL security testing
GraphQL gives clients a flexible query language over a single endpoint. That flexibility changes the security picture: one endpoint can expose your entire data model, and one query can ask for a very large amount of work. How it works Introspection, ...
Adding DAST to your CI/CD pipeline
Security testing is most useful when it happens automatically, on every build, rather than once before a big release. Adding DAST to your CI/CD pipeline catches new vulnerabilities while the change is still fresh in the developer's mind. How it works ...
Reducing false positives in DAST
False positives are the biggest reason teams stop trusting security scanners. When developers spend time on findings that turn out not to be real, they start ignoring the real ones too. How it works Scanners infer vulnerabilities from responses. ...
How to scan production safely
Staging environments rarely match production exactly. Sometimes you need to test the live site, but an aggressive scan can create records, send emails or slow the service down. A few precautions make production scanning safe. How it works Active ...
Scoping a security scan correctly
Scope decides what a scanner may discover and what it may attack. A scope that is too narrow misses vulnerabilities; one that is too wide wastes time, hits third-party systems or breaks things. How it works Scope has several parts: which hosts are ...
Scanning applications behind a WAF or rate limits
Web application firewalls (WAFs) and rate limits protect production, but they also block security scanners. A scan that was silently blocked looks exactly like a clean scan, which is dangerous. How it works The WAF recognises attack payloads and ...
Verifying security fixes with retesting
A vulnerability is not fixed until someone has checked the fix. Developers are confident, but partial fixes, fixes in the wrong environment and regressions are common. Retesting closes the loop. How it works After a fix is deployed, the same test ...
Compliance reporting from DAST results
Auditors and customers increasingly ask for evidence of regular application security testing. Standards such as PCI DSS, ISO 27001, SOC 2, HIPAA and NIST 800-53 all expect vulnerabilities to be identified and fixed. DAST results, mapped to those ...
Scheduling recurring security scans
Applications change every week: new features, new dependencies, new configuration. A single annual test quickly goes out of date. Recurring scans keep your security picture current with no extra effort. How it works A schedule runs the same scan ...
Top mistakes in web vulnerability assessments
Thousands of new vulnerabilities are reported in software every year, and many stay open for weeks or even years while organisations struggle to manage them. These are some of the most common mistakes made during web vulnerability assessments, and ...
Why web vulnerability testing should be automated
Whether you run a website or simply use one, you want to know that it is secure. Browsers help a little: they warn you when a site's connection is not secure. But a browser warning only covers the connection. It says nothing about weaknesses inside ...
Why web applications need security testing
In simple terms, web testing means checking a web application for problems before it goes live, or before new code reaches production. It covers how the site functions, how accessible it is, how it handles traffic and, critically, how secure it is. ...
How to find vulnerabilities in a website
Finding web vulnerabilities and closing them proactively is a must for any business today. Many organisations lack the tools and expertise to identify the weaknesses in their applications. This article explains the main ways to find them. What is a ...
Penetration testing tools: what they are and why they matter
Penetration testing is a controlled attempt to break into your own systems, to find weaknesses before a real attacker does. It answers a simple question: what could an attacker actually do to my application or organisation? What a penetration test ...
Why web application security testing is important
So much of daily life now happens online, from shopping to paying bills and applying for school admission. If you run a company or organisation, your website is your front door and a core part of your brand. If it is not secure, the damage to your ...
Web application vulnerability assessment checklist
A vulnerability assessment identifies the security weaknesses in a web application and rates each one by severity. This checklist covers the whole process in 14 sections and 118 checks, from planning to retesting. It follows the way the OWASP Web ...