Website Security

Find exploitable weaknesses, explain the user or business impact, and provide practical fixes with verification. Work across source code, deployment configuration, and runtime behavior according to available access. A browser-only review cannot verify server-side payment integrity or database isolation.

Start with scope, then keep working

1. Read applicable repository instructions. Identify the supplied repository, target origins, environment, and existing authorization. Infer the stack from manifests, routes, migrations, infrastructure, and integrations; do not assume a framework or gateway.
2. Record scope: repository revision or working-tree snapshot, exact origins, production/staging/local, identities and tenant fixtures, permitted actions, exclusions, and available access. Separate a local code audit from a deployed-site assessment.
3. A request to audit the user's site authorizes source/configuration review and ordinary browsing of that site. An explicit pentest request covers bounded tests of the identified user-controlled target; it does not include unrelated hosts, provider infrastructure, real charges, or destructive activity. Reuse authorization already given. If permission for a remote target is unclear, request missing scope while continuing local review. Read execution.md before active testing.
4. Choose the useful mode: source review, runtime review, scoped pentest, or remediate and retest. Combine when possible. Start with available access; ask only for missing access that materially affects the next test. Never ask for secret keys in chat.
5. For a broad website audit, cover all 12 domains below. For a narrow request, focus on that feature and its trust boundaries; do not silently turn it into a full audit.

Map the attack surface

Trace browser → edge/CDN → application/API → database/storage → payment/identity/other providers → webhook/worker → fulfillment or privileged action. List public, authenticated, administrative, background, and preview surfaces. Include recovery, invites, checkout, downloads, refunds, exports, OAuth callbacks, server actions, and webhooks when present.

Record who controls each input and where the server makes the security decision. Prioritize money movement, account takeover, cross-tenant access, sensitive data, and privileged execution before cosmetic hardening. Read coverage.md to select concrete checks.

If payments exist, read payments.md and trace the complete path through fulfillment. Hosted checkout does not prove the merchant integration is secure. For frontend-heavy/serverless stacks or managed databases, read stack-adapters.md.

Inspect and test

• Inventory routes, handlers, data rules, lockfiles, deployment files, jobs, and client assets. Search filenames first for likely secret-bearing files; use redacted secret-scanner output. Do not dump environment files, credentials, private records, or unredacted scan output into the conversation.
• Follow suspicious input to the sensitive operation and inspect guards at every layer before claiming a vulnerability. A search hit is a lead, not proof. Inspect middleware, framework protections, policies, and deployment configuration affecting reachability.
• Use available tools appropriate to the stack: dependency/secret/static analysis, HTTP/browser inspection, framework tests, database policy tests, or a scoped web scanner. Check installed versions and help before choosing flags. Follow execution.md; no tool is mandatory and missing tools do not block unaffected work.
• For important boundaries, establish a legitimate positive control, change one assumption, observe rejection or unintended effect, and check authoritative state. Use synthetic accounts A and B across tenants. Include anonymous, lower-privilege, expired/revoked, and wrong-owner cases where relevant.
• Manually triage scanner detections. Confirm advisory applicability against resolved package versions and official advisories. Distinguish a vulnerable dependency's presence from a reachable exploit; inspect the lockfile, not just version ranges.
• Missing evidence of a control is not proof of its absence. A 200 response does not prove unauthorized success; a 403 does not prove no side effect occurred. Check body, ownership, persistent state, and asynchronous work.

Evidence and decisions

Use reporting.md and the report template. Maintain a test ledger: IDs, prerequisites, expected/actual results, status, evidence. Statuses are pass, fail, inconclusive, not-tested, or not-applicable, with reasons for the last three. A domain with untested controls has partial coverage.

Every finding needs a demonstrated runtime result or complete source/configuration path, affected surface, attacker prerequisites, credible impact, severity rationale, confidence, and specific fix. Label source-only findings and unexecuted reproductions clearly. Separate hardening advice from exploitable findings. Consolidate shared root causes while recording affected surfaces.

Never claim “unhackable,” certify compliance, invent results or CVE/ASVS IDs, or use a percentage as a security guarantee. Report assessment time, scope, gaps, and residual risk. Verify precise framework/provider behavior and standards identifiers in current official sources using sources.md; mark unavailable verification rather than inventing detail.

Remediate and retest

When the user requests fixes, make focused, reversible repository changes preserving product behavior. Enforce the rule where data is trusted: server, database, or verified provider boundary. Avoid broad dependency upgrades or weakening protections to make a test pass.

Add a regression test for each meaningful bug, then verify the exploit fails and the legitimate flow succeeds. Check neighboring roles, tenants, error/retry paths, and asynchronous effects relevant to the fix. An unrun test is proposed, not verified. Distinguish fixed-but-not-retested from verified-fixed; a local patch is not a deployed fix.

Prepare deployment, secret rotation, data repair, external changes, or destructive migrations as reviewable actions and follow existing authorization. An audit-only request produces recommendations without silently changing the application. Do not rotate secrets or disable production merely because an audit found a concern.

Deliver

Save a dated report in an appropriate project output directory, using the template and a test ledger. Audit-only work may create isolated harnesses and evidence files in the audit output directory; modify application code or its maintained regression suite only within remediation scope. Lead the final answer with consequential findings and the launch recommendation, then link the report and state material access gaps. If interrupted, deliver completed evidence and unfinished checks. Produce a defensible assessment and actionable fixes, not speculative warnings.