Runtime Probe

Reading code tells you what the handler intends. Sending a request tells you what the stack actually does. Middleware ordering, framework defaults, a route registered twice, an error handler that leaks in one branch — these only show up when something is running.

This skill is invoked deliberately. It does not run on its own, and it does not run while code is being written.

Target rule — check this before sending anything

Send no request until all of the following are true:

1. The target is localhost, a loopback address, or a development or staging host.
2. The user has confirmed, in this conversation, that they own or control it.
3. It is not production, not shared with real users, and holds no real user data.

If the host is unfamiliar, if the user has not said which environment it is, or if anything suggests real traffic, stop and ask. Do not infer from a hostname that merely contains "dev" or "staging" — ask.

Refuse outright, without negotiating, if the target is production, someone else's system, a third-party service, or any host the user has not confirmed is theirs. Probing infrastructure you do not control can breach the provider's terms regardless of intent, and attack traffic against live systems corrupts data and trips defenses. A dev instance runs the same code, so there is nothing to gain from the riskier target.

Setup

Before probing, establish:

• Two seeded users, A and B, with separate resources, and valid credentials for each. Most authorization testing is vacuous without a second user to reach across.
• A non-admin and an admin, if the app has roles.
• Known fixture data, so a finding can name the specific record that leaked.
• A way to reset state, so mutating probes can be re-run.

If the app cannot be seeded this way, say so and probe only what is testable rather than improvising accounts.

Probes

Work down this list. Most apps fail on the first group and pass the rest.

Cross-user access. For every endpoint returning or mutating a resource, authenticate as B and request A's object. Vary where the identifier sits: path parameter, query string, request body, a nested field, a batch or filter parameter. List endpoints deserve their own attention — a collection route that ignores the owner filter leaks everything at once.

Unauthenticated reachability. Repeat the same requests with no credentials, and with a malformed or expired token. A route missing from the auth middleware's matcher looks correct in code and is wide open in the router.

Privilege boundaries. Authenticate as a regular user and call admin endpoints directly. Hidden in the UI is not access control.

Trusted client input. Replay a legitimate request with a meaningful value changed — price, quantity, role, status, owner ID, discount. Anything the server accepts rather than re-deriving is a finding.

Error leakage. Send malformed bodies, wrong types, nonexistent IDs, and oversized payloads. Look for stack traces, SQL fragments, file paths, framework and version banners, and internal hostnames in the response.

Token handling. Present an expired token, a token signed by nobody, a token belonging to the other user, and a token with a modified payload. Each should be rejected the same way.

Cookies and headers. Check session cookies for HttpOnly, Secure, and a sane SameSite. Note missing X-Content-Type-Options, and the absence of a CSP where one would matter. Report these as a short list at low priority — they are real but they are not what gets an app breached, and leading with them buries the findings that do.

Auth endpoint behavior. Does login respond differently for an unknown user than for a wrong password? That is account enumeration. Check for rate limiting with a small, bounded number of attempts — enough to see whether a limit exists, not enough to stress the instance.

Conduct

• Prove reachability, not exploitation. A response containing another user's record is a complete finding. Do not escalate, pivot, dump a table, or chain one finding into another. The point is to show the door is open, not to walk through it.
• No weaponized payloads. Benign markers are sufficient to show input reaches somewhere it should not.
• Mutate only seeded data. Never delete in bulk, never touch anything you did not create.
• Keep volume low. A few hundred requests, not thousands. This is a correctness check, not a load test.
• Stop on instability. If the instance starts erroring or slowing, stop and report what was covered.

Output

A ranked table. Endpoint, probe, what happened, what it means, severity.

Rank by what an attacker actually gets: another user's data or the ability to change it first, then privilege escalation, then information disclosure, then header and cookie hygiene last.

Every finding ships with a failing test, written in the repo's existing framework, asserting the correct behavior:

def test_user_b_cannot_read_user_a_order():
    resp = get(f"/orders/{user_a_order.id}", as_user=user_b)
    assert resp.status_code == 404

The test is the deliverable. It fails now, passes after the fix, and stays in the suite so the hole cannot reopen quietly.

Close with what was not covered — endpoints that could not be reached, flows that needed data you could not seed, anything skipped. A probe has edges; name them.

Honest limits

This finds common, mechanical failures in a running app. It does not find business logic flaws, race conditions, cryptographic weaknesses, supply chain compromise, or anything in your infrastructure, and it will not find what a competent human attacker would.

A clean run means these probes passed. It does not mean the application is secure, and it is not a penetration test. Say this explicitly in the summary. A security tool that produces false confidence is worse than no tool at all.

If the build-time hardening pass has already been run on this code, expect few findings. That is the intended outcome, not a failed probe.