PHP Security Testing

When to use

• The user wants to write tests that assert authentication and authorization — who can reach an endpoint and who gets 401 or 403.
• The user wants to test that the app resists injection and malicious input — SQL injection, XSS payloads, path traversal, and other untrusted-input attacks.
• The user wants to assert security response codes and behavior — 401 unauthenticated, 403 forbidden, 429 rate-limited, and CSRF-token rejection.

When NOT to use

• Do not treat automated security tests as a substitute for a scoped manual penetration test or professional audit before a high-risk launch.
• Do not frame ordinary business-logic or formatting tests as security tests; keep them as plain unit or feature tests.

Core guidance

• Assert the exact status code and no data leak — Assert the precise status (401 vs 403 vs 404 vs 429) and that the response body leaks no protected data, rather than only checking the request "failed".
• Drive injection tests from a payload dataset — Feed a dataset of known-malicious inputs (SQLi, XSS, path traversal, null bytes) into one parameterised test and assert each is rejected or safely neutralised.
• Assert denial, not just success, for every control — For every protected action, write a negative test that the wrong actor is denied (401/403) in addition to the positive test that the right actor succeeds.

Decision Engine

Walk this section before choosing an implementation path.

What is the concern — access control, untrusted input reaching a sink, robustness of
a parser, or whole-app runtime posture?

├── The concern is who may perform an action: → write a feature test hitting the route as each role — assert 200 for the allowed
actor and 401/403 for everyone else, plus no data leak in the denied body.

├── Untrusted input can reach a query, view, or shell: → write a dataset-driven test feeding known SQLi/XSS/traversal payloads and assert
each is parameterised, escaped, or rejected, backed by SAST taint analysis in CI.

├── A parser, decoder, or upload handler must survive hostile input: → add fuzzing or property-based tests that throw random, oversized, and malformed
input and assert no crash, hang, or unintended path — catching DoS and encoding bugs.

└── You need to probe the deployed app's runtime posture: → run a DAST scanner (e.g. OWASP ZAP) against a staging build to catch headers,
misconfig, and reachable endpoints that unit and feature tests never exercise.

Full engine: references/decision-engine.md — Decision Tree, Priority Matrix, Decision Table.

Workflows

Workflow: Authz Suite

Progress:
- [ ] In a Pest/PHPUnit feature test, create the owner (or privileged role) and a second
unrelated user, plus the resource the endpoint protects
- [ ] Hit the route three ways — as the owner (expect 200), as the other user (expect
403), and with no auth (expect 401) — using the app's HTTP test client
- [ ] On the 403 case, additionally assert the response body does not contain the
protected record's fields, then wire the test into CI

1. In a Pest/PHPUnit feature test, create the owner (or privileged role) and a second unrelated user, plus the resource the endpoint protects.
   • Verify: Both users and the target resource exist in the test database.
2. Hit the route three ways — as the owner (expect 200), as the other user (expect 403), and with no auth (expect 401) — using the app's HTTP test client.
   • Verify: All three status assertions pass against the current policy.
3. On the 403 case, additionally assert the response body does not contain the protected record's fields, then wire the test into CI.
   • Verify: Reintroducing the record into the 403 body fails the test in CI.

Workflow: Injection Suite

Progress:
- [ ] Define a dataset of attack strings — SQLi (`' OR 1=1 --`), XSS
(`<script>alert(1)</script>`), path traversal (`../../etc/passwd`), and a null byte
- [ ] For each payload, submit it through the real endpoint and assert the safe effect —
stored/echoed escaped, no extra query rows, no schema-revealing error
- [ ] Add a taint-aware SAST run (e.g

1. Define a dataset of attack strings — SQLi (' OR 1=1 --), XSS (<script>alert(1)</script>), path traversal (../../etc/passwd), and a null byte.
   • Verify: The dataset is bound to the test with a Pest dataset or PHPUnit data provider.
2. For each payload, submit it through the real endpoint and assert the safe effect — stored/echoed escaped, no extra query rows, no schema-revealing error.
   • Verify: Each dataset row runs as its own case and asserts neutralised output.
3. Add a taint-aware SAST run (e.g. Psalm --taint-analysis or PHPStan taint rules) to CI so any new untrusted-to-sink flow fails even without an explicit payload.
   • Verify: Introducing a raw concatenation into a query is caught by SAST in CI.

Best practices

• Add tests that a state-changing request without a valid CSRF token or nonce is rejected, and that exceeding the rate limit returns 429 with a Retry-After
• For parsers, decoders, and upload handlers, add basic fuzzing or property-based tests that throw random, oversized, and malformed input and assert the code never crashes, hangs, or executes unintended paths
• Run static analysis security tools (SAST such as Psalm/PHPStan taint analysis) on every push and schedule dynamic scans (DAST such as OWASP ZAP) against a staging build, treating both as gates beside your Pest/PHPUnit security tests

Anti-patterns

See references/anti-patterns.md.

Debugging

1. Protections disabled globally in the test env — Disabling a protection to make ordinary feature tests simpler means a regression in that protection produces no failing test anywhere. Fix: Keep protections enabled and, where they get in the way, bypass them per-test via an explicit helper while retaining dedicated tests that exercise them.
2. Only the authorized path is tested — The deny branch is the security-relevant one; without it, removing a policy check or a middleware goes unnoticed until it is exploited in production. Fix: For every positive access test add a negative one that asserts 401/403 for an actor who must not have access.
3. Injection test asserts status, not effect — For most injection classes a 200 is expected either way; the security property is whether the payload was neutralised, not whether the request completed. Fix: Assert the safe effect — the value is stored/rendered escaped, the query returns no extra rows, and no error discloses the schema.

Production checklist

• A tokenless write is asserted rejected and exceeding the limit returns 429 with Retry-After.
• Each protected action has a negative test proving the wrong actor gets 401 or 403.
• A shared malicious-input dataset (SQLi, XSS, traversal) drives a parameterised test asserting safe handling.
• Security tests use disposable fixtures and fake credentials, never real production secrets or live PII.
• Static security analysis (taint-aware SAST) runs on every push and fails the build on new findings.
• Denied responses assert the exact status code and that no protected data appears in the body.

Version notes

• composer audit ships with Composer 2.4+ (PHP >=8.1) — composer audit for scanning installed packages against the advisory database is built in from Composer 2.4; on older Composer use the roave/security-advisories package or the local-php-security-checker binary instead.
• Pest arch presets help enforce security invariants (PHP >=8.1) — Pest 2+ arch tests (arch()->expect(...)) and Pest 3's expanded presets let you assert security invariants such as "no debug functions" or "controllers depend on a policy", complementing per-request security tests.

Security

• Keep attack payloads and secrets out of production paths — Run security tests only against an isolated test database and disposable fixtures, never against production or a shared staging store, and keep attack payloads and any test secrets out of source that ships to production.

Testing

• Activation and decision behavior are verified in eval/scenarios/testing/security-testing.yaml.
• Assert the precise status (401 vs 403 vs 404 vs 429) and that the response body leaks no protected data, rather than only checking the request "failed".
• Add tests that a state-changing request without a valid CSRF token or nonce is rejected, and that exceeding the rate limit returns 429 with a Retry-After.
• Feed a dataset of known-malicious inputs (SQLi, XSS, path traversal, null bytes) into one parameterised test and assert each is rejected or safely neutralised.
• For parsers, decoders, and upload handlers, add basic fuzzing or property-based tests that throw random, oversized, and malformed input and assert the code never crashes, hangs, or executes unintended paths.
• Run static analysis security tools (SAST such as Psalm/PHPStan taint analysis) on every push and schedule dynamic scans (DAST such as OWASP ZAP) against a staging build, treating both as gates beside your Pest/PHPUnit security tests.
• For every protected action, write a negative test that the wrong actor is denied (401/403) in addition to the positive test that the right actor succeeds.

Additional resources

• references/anti-patterns.md
• references/core.md
• references/decision-engine.md
• references/examples.md
• references/pitfalls.md
• references/recipes.md
• references/version-differences.md

Knowledge graph

Related: security/sql-injection-prevention, testing/pest-basics

Skill contract

Produces: test.security-suite
Requires: security.owasp-reviewed
Risk: medium · Confidence: 0.85