Scope and Safety

Active testing sends real attack traffic at a live system. This page describes exactly what Codity will touch, what it refuses to touch, and how that boundary is enforced — which is usually what your infrastructure team, your hosting provider or your customer's security reviewer will want to see in writing.

Codity only tests what you have proven you own

Ownership is not a setting you tick. Your organization publishes a cryptographically random token in your domain's DNS or on your web server, and Codity confirms it before the domain can be used at all. See Domain Verification.

The check is not made once at setup and then trusted. Every run re-resolves the domain and the target from your organization's own verified records at the moment it starts, and refuses to proceed if verification is missing.

What a scan is allowed to reach

• Only hosts inside your verified domain. A target URL outside it is rejected when the target is saved.
• Only public addresses. Every address a scan resolves must be globally routable. Private, loopback, link-local, cloud metadata, multicast and reserved ranges are refused.
• Only the exact host you configured. A redirect that leads to a different host is refused rather than followed, so a scan cannot be walked off your property by a redirect on your own site. Any result that does turn out to be off-host is dropped before the report is written.
• Nothing that arrives late. The address approved during validation is the address used for the scan, so a DNS record that changes mid-run cannot redirect traffic somewhere else.

Anything a scan somehow observes outside the configured host is discarded before it is written to your report.

Where the traffic comes from

Active scans run in an isolated, per-run environment that is created for your assessment and destroyed afterwards. Credentials are decrypted only inside it. Nothing from one customer's assessment is visible to another's.

What a black-box scan does

Nothing to your application. It reads information that is already published about your organization — certificate transparency records, public DNS, and public network registration data. Your servers receive no requests from Codity during a black-box scan, which is why it is safe to run against production at any time, and safe to run against systems you do not host. The report records that no traffic was sent to the target.

What an active test does to your application

It behaves like a determined user with a browser and an intercepting proxy. It:

• Requests pages, follows links, and submits forms
• Discovers API endpoints and parameters
• Sends manipulated values into those parameters and reads the responses
• Retries variations of anything that looks interesting

Which means, plainly:

• It creates traffic. Expect load comparable to a small burst of real users for the duration of the run.
• It can create, change or delete data that the account you supplied is permitted to create, change or delete. Forms get submitted. Records get created.
• It can trigger your alerting. Your WAF, IDS or rate limiter may fire, and your on-call may be paged.

Recommended precautions

1. Run the first assessment of a new application against staging.
2. Supply a dedicated test account with ordinary user permissions, not an administrative one.
3. Tell your on-call and, if relevant, your hosting provider before the first production run.
4. Allow-list or relax rate limiting for the run if you want coverage rather than a report full of blocked requests. A WAF that blocks the scan produces a clean report that proves very little about the application behind it.
5. Prefer a low-traffic window for Deep assessments on production.

warning

Only run active tests against systems your organization owns or has written authorization to test. Domain verification proves you control the name; it does not, by itself, constitute permission from a third party whose infrastructure you happen to be hosted on.

Credentials

• Stored encrypted; never written to logs
• Released only to the isolated environment running your scan
• Redacted from the request and response evidence kept in your report, so a report can be shared without leaking a session
• Deleted when you switch a target back to unauthenticated

What automated testing cannot do

An honest report says what it did not cover. Codity's assessments do not replace a human engagement for:

• Business logic flaws — an automated test does not know that a discount code should not be applicable twice, or that this user should not be able to approve their own request.
• Complex, chained exploitation — combining several individually minor issues into one serious one is human work.
• Multi-step authorization reasoning — whether user A should be able to reach user B's record is a question about intent, not about a response code.
• Anything outside the crawl — a page no link points to, behind a workflow the crawler cannot complete, is not assessed.

Absence of a finding is evidence, not proof. The reports state this, which is part of what makes them credible to reviewers.

Stopping a scan

Active tests are bounded by their scan mode's time budget — 15 minutes, 1 hour or 4 hours — and stop on their own. A scan cut off at its budget keeps what it had already proven and is recorded as a partial run, so the short report is not mistaken for a clean one. If you need a run to stop sooner — an incident, an unexpected load problem — contact support and block the traffic at your edge in the meantime.