A DAST or API security testing tool holds working logins for your applications, a map of their endpoints and a list of every weakness it has found, and it can send attack traffic on command, so whoever controls it has a ready-made attack kit aimed at you. Dynamic application security testing and API testing tools store test credentials and recorded login sequences, import API definitions, run scan engines inside your networks, keep findings, and integrate with CI pipelines and ticketing. This guide is for application security leads, DevSecOps engineers and platform owners who run such a tool, hosted or self-hosted. It covers admin roles, the credentials the tool holds and uses, scan engines, target scope, findings data, logs, hardening and lifecycle. How to test applications well is in the Web Application Security Testing Guide; this page is about protecting the tool itself. It is vendor-neutral: confirm the exact setting names in your vendor's documentation.
Key takeaways
- Findings are sensitive data. NIST SP 800-115 notes that results from any security test identify vulnerabilities; protect the findings store like the most sensitive data in the applications it scans.
- Test credentials are real credentials. Every stored login, token and recorded sequence is a working way into an application; scope, vault, rotate and monitor them.
- Lock scope to approved targets. A tool that can scan any address can be pointed at third parties or used to probe internal systems; enforce a verified target allowlist.
- Treat internal scan engines as privileged network assets. An engine inside a segment can reach what it scans, so harden it, restrict its egress and control what it can be told to do.
- Keep the tool's audit log elsewhere. Role changes, target and policy edits, credential changes and findings exports belong in a store tool admins cannot alter.
What the tool holds and why it matters
NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, says in its data handling section that storing assessment data is the assessors' responsibility, that sensitive assessment data should be isolated physically or logically from day-to-day network resources, and that access should be limited to the individuals who need it. Its rules of engagement template asks for authorised tools to be identified and for clear requirements on gathering, storing, transmitting and destroying test data. A DAST platform is where all of that data now lives.
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Console and tenant settings | Users, roles, targets, scan policies, integrations | Reads findings, adds targets, launches scans, adds admins | SSO with phishing-resistant MFA, few admins, scoped roles |
| Credential store | Test usernames and passwords, MFA seeds, API keys, OAuth client credentials, recorded login scripts, session cookies | Logs into your applications as test or service identities (T1552.001) | Vaulted storage, per-application test identities, rotation, use monitoring |
| API definitions and site maps | OpenAPI and GraphQL schemas, discovered endpoints, internal hostnames | Full map of attack surface, including hidden endpoints | Access by application, retention limits |
| Findings store | Confirmed vulnerabilities with proof, request and response samples, sometimes personal data | A prioritised exploitation list (T1213) | Restricted access, redaction of response data, encryption, retention |
| Scan engines and agents | Network position inside segments, ability to send attack traffic | Pivot or launch point inside your network | Hardened hosts, egress control, signed updates, health alerts |
| CI and API tokens | Trigger scans, read results, gate builds | Disables gates or exports findings through the API | Scoped, expiring tokens per pipeline, federation where supported |
| Integrations (ticketing, chat, SIEM, out-of-band callback service) | Outbound credentials and webhooks | Leaks findings to the wrong place | Per-integration credentials, destination allowlist |
Admin roles and console access
- Role design: separate platform administrator (settings, roles, integrations, engines), target owner (registers and verifies targets for their applications), scan operator (configures and runs scans within approved targets and policies), triager (reviews findings for assigned applications) and read-only reporter. Creating targets and editing scan policies are high-impact rights.
- Scope findings by application: developers should see findings for their own applications, not the whole portfolio. In our view, a single team account with organisation-wide findings access is an avoidable exposure.
- Authentication: SSO with phishing-resistant MFA, role assignment from identity provider groups and one tested break-glass account. NIST SP 800-115 suggests two-factor authentication for assessment systems that store sensitive data. The CISA and FBI Secure by Demand guide suggests asking whether SSO is offered at no additional cost and whether MFA or passkeys are on by default. See the Break-Glass Account Guide.
- Admin devices: follow the NCSC secure system administration principles: trusted management devices, protected admin interfaces, privileged access removed when not needed and all administration logged. See the Privileged Access Workstations Guide.
- External testers: give penetration testers and consultants named, time-bound accounts scoped to their engagement's targets, removed the day the engagement ends. See the Third-Party Access Guide.
- Review: review roles, target owners and external accounts every quarter (our recommendation).
Credentials the tool holds and uses
| Credential | Needs | Avoid | Pattern |
|---|---|---|---|
| Application test accounts | Log in as each role under test, in one environment | Real user or administrator accounts; one account across environments | Dedicated per-role, per-environment test identities, flagged as test in the directory |
| MFA seeds for test accounts | Complete MFA during authenticated scans | Disabling MFA for test accounts in production | Seed stored in the tool's vault, test account limited by source address |
| API keys and OAuth clients for API testing | Call the API under test with defined scopes | Production keys with write scopes for unrelated data | Test clients with minimum scopes and short-lived tokens |
| Recorded login sequences and session cookies | Re-authenticate during scans | Long-lived session cookies copied from a person's browser | Scripts that use vaulted credentials; no captured personal sessions |
| CI pipeline tokens | Trigger scans and read results for one project | Organisation admin tokens in pipeline variables | Per-project scoped token, or federated pipeline identity where supported |
| Engine registration keys | Enrol a scan engine with the platform | Shared, non-expiring keys reused for every engine | Per-engine key or certificate, revoked when the engine is retired |
- Govern test identities: each test account has an owner, an application, an environment and an expiry, and appears in your identity inventory. See the Test and Synthetic Accounts Governance Guide.
- Rotate and monitor: rotate stored test credentials at least every 90 days and after every external engagement (our recommendation), and alert when a test account is used outside scan windows or from addresses other than your engines.
- Keep secrets out of pipeline files: inject scan tokens from the CI secret store or federation. See the CI/CD Pipeline Identity Security Guide and the Secrets Management Guide.
Target scope and scan policy
A scanner that will scan whatever address it is given can be turned against third parties, internal systems you did not approve or production systems with destructive checks.
- Verified target allowlist: scans run only against registered targets, each owned by a named person and verified (for example by DNS record or file placement, where the tool supports it). Adding a target needs the target owner role.
- Policy by environment: production targets get passive or explicitly safe policies; active and potentially destructive checks run only against test environments or duplicates, as NIST SP 800-115 suggests testing duplicates of production systems to reduce risk.
- Scan windows and rate limits: schedule production scans in agreed windows with request rate limits, and register engine source addresses with the SOC so authorised scans are distinguishable from attacks.
- Restrict engine egress: internal engines should reach only their assigned targets and the platform. Block cloud metadata addresses and unrelated internal ranges at the network layer, following the network-layer controls in the OWASP SSRF Prevention Cheat Sheet. See the SSRF Prevention Guide.
- Out-of-band callbacks: if the tool uses an external callback service to detect blind vulnerabilities, understand what data reaches it and prefer a private callback service for sensitive applications.
Protecting findings and scan data
- Isolate and restrict: NIST SP 800-115 asks for assessment data to be isolated from day-to-day resources, limited to those who need it, and encrypted. Apply application-level access to findings and encrypt the findings database and backups.
- Redact evidence: request and response samples can contain personal data, tokens and session cookies. Redact authorisation headers and cookies in stored evidence where the tool allows it.
- Retention and destruction: set retention for raw scan data and evidence, and define destruction in line with NIST SP 800-88 sanitisation categories, which SP 800-115 references.
- Export controls: limit bulk export to a few roles and alert on large exports or API reads.
- Vendor access: for hosted tools, confirm whether vendor staff can see findings and evidence, and how that access is approved and logged.
The tool's own logs
| Event to capture | Why it matters | Alert? |
|---|---|---|
| Role, SSO or user change; external account added | Persistence and widened access (T1078) | Always |
| Target added or verification bypassed | Scanner pointed somewhere unapproved (T1595) | Always |
| Scan policy changed to active or destructive on production | Outage or data damage risk | Always |
| Stored credential added, viewed or changed | Credential theft or misuse (T1552.001) | Always for production targets |
| Findings exported or bulk API read | Data theft (T1213) | Above baseline |
| CI gate disabled, finding suppressed or marked false positive | Hides a real weakness | Bulk or critical-severity changes |
| Engine registered, offline or updated | Rogue or broken engine (T1685) | Always for registration |
- Export it: stream the audit log to a SIEM the tool's admins cannot alter. NIST SP 800-53 AU-9(2) covers storing audit records on a separate system and AC-6(9) covers logging privileged functions. NIST SP 800-115 also recommends logging assessor activity, including date and time, assessor, target, tool and command.
- Retention: Secure by Demand asks SaaS providers to keep security logs for at least six months at no additional charge; export if your plan keeps less.
- Suppression is a security event: marking findings as false positives or accepted risk should record who, why and an expiry, because it is the quietest way to hide a vulnerability.
Hardening and lifecycle
- Engines: run self-hosted engines on dedicated, hardened hosts or ephemeral containers, keep them updated (SP 800-115 asks for scanner signatures to be updated before each run) and remove standing interactive access.
- Platform updates: apply vendor security updates promptly and subscribe to the vendor's security advisories page.
- Least functionality: disable features you do not use, such as manual proxy or attack modules, for roles that do not need them (CM-7).
| Stage | Security actions |
|---|---|
| Buy | Ask the Secure by Demand questions; confirm target verification, role and application scoping, credential vaulting, evidence redaction, audit log export, data residency and vendor staff access. See the Application Security Testing Buyer's Guide and Application Security Testing RFP Template. |
| Deploy | Enable SSO first; create roles and application scopes; register and verify targets; create dedicated test identities; place engines with restricted egress; turn on audit export on day one. |
| Run | Quarterly review of roles, targets, test identities, tokens and suppressions; credential rotation; engine patching. |
| Respond | If the tool or an account is suspected compromised: pause scans, rotate every stored test credential and token, review targets, exports and suppressions since the first suspicious event, and alert application owners whose findings may be exposed. |
| Retire | Export findings history you must keep, delete stored credentials and disable test identities, revoke engine keys and CI tokens, decommission engines, and obtain written confirmation of data deletion (MP-6). |
Roll back a hardening change, such as narrowing an engine's egress, by keeping the previous rule documented and opening only the specific target a scan reports as unreachable, never a whole network range.
Detection and measurement
- Percentage of scan targets registered, owned and verified (target: 100 per cent).
- Number of users with organisation-wide findings access (target: five or fewer, our suggestion).
- Percentage of stored test credentials rotated within 90 days.
- Test account sign-ins outside scan windows or engine addresses (target: zero unexplained).
- Suppressed critical and high findings without an expiry (target: zero).
- Days of tool audit log available in the SIEM.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | Threat addressed |
|---|---|---|---|
| Console roles and scoped findings access | AC-2, AC-6, AC-6(5) | PR.AA-05 | T1078 Valid Accounts |
| Test credentials and tokens | IA-5, RA-5(5) | PR.AA-01 | T1552.001 Credentials In Files |
| Scanning and testing activity | RA-5, CA-8, SA-11 | PR.PS-01 | T1595 Active Scanning (misuse of the tool) |
| Findings and evidence data | SC-28, MP-6 | PR.DS-01 | T1213 Data from Information Repositories |
| Audit log protection | AU-9(2), AC-6(9) | PR.PS-04 | T1685 Disable or Modify Tools |
| Vendor and hosted service | SA-9, SR-3 | GV.SC-07 | T1199 Trusted Relationship |
Common failure patterns
- Real administrator accounts for authenticated scans: a person's admin login is stored in the tool because it was quickest to set up.
- Everyone sees every finding: a shared team role exposes the full vulnerability backlog for every application.
- Open targeting: any operator can scan any hostname, including systems the organisation does not own.
- Flat engine network access: an internal engine can reach every segment and the cloud metadata service.
- Silent suppressions: critical findings are marked false positive with no reason or expiry.
- Audit trail left inside the tool: target, credential and export history exists only in the console an attacker controls.
Practitioner checklist
- Classify findings, evidence and stored credentials as sensitive data, with encryption, retention and destruction rules.
- Enforce SSO with phishing-resistant MFA, group-based roles and a tested break-glass account.
- Separate platform admin, target owner, scan operator, triager and reporter roles, and scope findings by application.
- Use dedicated per-role, per-environment test identities with owners, expiry and use monitoring.
- Vault test credentials, MFA seeds and tokens, and rotate them every 90 days and after each engagement.
- Enforce a verified target allowlist, safe policies on production and scan windows registered with the SOC.
- Restrict scan engine egress to assigned targets and block metadata and unrelated internal ranges.
- Export the audit log to a store tool admins cannot change and alert on targets, credentials, exports and suppressions.
- Review roles, targets, identities, tokens and suppressions every quarter, and keep a decommissioning checklist.
Standards and references
- NIST: SP 800-115 Technical Guide to Information Security Testing and Assessment
- OWASP: Server Side Request Forgery Prevention Cheat Sheet
- NCSC: Secure system administration
- CISA and FBI: Secure by Demand Guide
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Web Application Security Testing Guide · API Penetration Testing Guide · Application Security Testing Buyer's Guide · Test and Synthetic Accounts Governance Guide · Securing the identity threat detection and response (ITDR) tool itself