Sensitive endpoints

Use environment constraints to control where Qodex can run destructive, invasive, or high-volume security tests.

Sensitive endpoints

Security tests can be powerful. Some probes are safe to run almost anywhere, such as header checks. Others can create data, send attack payloads, or generate traffic bursts. Sensitive endpoint controls tell Qodex what it is allowed to do in each environment.

Use these controls to keep production safe while still getting meaningful security coverage in staging or preview environments.

The three environment constraints

Each environment can define three constraints:

Constraint	What it controls
read_only	Blocks write verbs such as POST, PUT, PATCH, and DELETE when set to true.
max_requests_per_second	Caps how fast Qodex can send requests during a run.
allow_destructive_tests	Blocks destructive payloads such as data deletion, destructive SQL payloads, or account deactivation when set to false.

The constraints combine. For example, a production environment can be read-only, rate-limited, and destructive-test disabled. A dedicated QA environment can allow broader probes.

Example configuration

{
  "name": "production",
  "hosts": {
    "api": "https://api.example.com",
    "ui": "https://app.example.com"
  },
  "variables": {
    "AUTH_EMAIL": "[e-mail]"
  },
  "readOnly": true,
  "maxRequestsPerSecond": 5,
  "allowDestructiveTests": false
}

Qodex reads these settings before authoring and before execution. If a planned probe violates the environment, the agent skips it or rewrites it to the safe subset.

Recommended defaults

Environment	read_only	max_requests_per_second	allow_destructive_tests
Production	true	5	false
Staging mirror of production	true	5	false
Dedicated QA staging	false	20	true
Local development	false	50	true
Preview deployment	false	20	true

Production should usually receive safe checks such as security-header audits, cookie audits, TLS checks, and read-only authorization probes. Write-side IDOR, mass assignment, injection, and high-volume rate-limit tests belong on staging or preview environments.

What happens when a probe is blocked

When constraints block a probe, Qodex handles it in one of three ways:

Outcome	What Qodex does
Probe is allowed	Authors and runs the scenario normally.
Probe is partly allowed	Keeps the safe steps and skips unsafe steps.
Probe is fully blocked	Skips the scenario and notes the reason in the run summary.

For example, on a read_only: true environment, a BOLA check can still test GET /api/orders/{id} with the wrong user token, but Qodex should skip the PUT and DELETE versions.

The runner also enforces rate limits, so a manually authored scenario cannot bypass the configured request ceiling.

Checking constraints in chat

Before running a security sweep, you can ask:

What constraints are set on the production environment?

Qodex will report the active environment flags so you can decide whether to run the check there or switch to a less restricted target.

When to tighten constraints

• The environment points to production or production data.
• The endpoint changes billing, permissions, users, or account state.
• The test includes brute-force, fuzzing, or burst behavior.
• The target is shared with customers or internal teams.
• You are not sure whether the endpoint has idempotent cleanup.

Related

Security scenarios

Learn how constraints shape the scenarios Qodex authors.

OWASP API Top 10 in Qodex

See which probes may need write access or higher rate limits.

Inverted semantics

Understand how security pass and fail states work.

Auth profiles

Configure roles for BOLA, IDOR, and privilege-escalation tests.

On the roadmap

A dedicated allow_security_testing flag is planned. It will let teams block active attack payloads independently from destructive tests, so production mirrors can still run hygiene checks without receiving injection or SSRF probes.