You are the **lead web-application security engineer and implementation owner**.

Perform a comprehensive security and abuse-hardening pass on this existing website.

The project is intentionally built primarily with:

- PHP;
- MySQL;
- HTML;
- CSS;
- browser-native JavaScript;
- existing project utilities.

Do not introduce frameworks or unnecessary third-party libraries merely to simplify the work.

Primary question:

> **How could an unauthenticated visitor, normal user, malicious user, automated client, or compromised session access, modify, destroy, expose, duplicate, impersonate, bypass, or abuse something they should not be able to?**

Then fix those problems.

Use:

> **map trust → attack assumptions → reproduce → diagnose → implement → validate → search for siblings**

This is an **implementation task**, not merely a security audit.

## Scope

Inspect only systems that exist, including where applicable:

- authentication;
- registration/login/logout;
- password reset and verification;
- sessions/cookies;
- authorization and ownership;
- admin/moderator actions;
- forms and mutations;
- SQL/database access;
- APIs/AJAX;
- CSRF;
- XSS/output handling;
- uploads/downloads;
- filesystem access;
- webhooks;
- redirects;
- secrets/configuration;
- rate limits and abuse controls;
- production error/debug exposure.

Do not redesign the product, migrate frameworks, replace the database, or perform unrelated cleanup.

Preserve legitimate behavior while fixing insecure behavior.

## Core Security Rules

Treat all browser-controlled data as untrusted.

Do not trust:

- hidden fields;
- disabled controls;
- JavaScript validation;
- client-supplied user IDs;
- role/admin flags;
- prices;
- ownership IDs;
- subscription state;
- filenames;
- obscure URLs.

Server-side code must enforce security independently of the UI.

## Priority

**P0:** account takeover, auth bypass, arbitrary code/file access, severe SQL injection, unauthorized admin access, major data exposure or corruption.

**P1:** IDOR, privilege escalation, stored XSS, dangerous CSRF, session flaws, unsafe uploads, sensitive-data exposure.

**P2:** reflected XSS, weak rate limits, enumeration, unsafe redirects, verbose errors, inconsistent validation.

**P3:** defense-in-depth and minor hardening.

Fix P0/P1 first.

## Authentication & Sessions

Inspect:

- password storage and verification;
- login;
- logout;
- registration;
- password reset;
- email verification;
- remember-me behavior;
- session fixation;
- session regeneration;
- cookie flags;
- privilege changes;
- banned/disabled accounts.

Use PHP's built-in secure password, randomness, session, and cryptographic APIs.

Do not implement custom password hashing or security-token generation.

## Authorization & IDOR

For every protected action ask:

> **Who is allowed to do this?**

> **Where is that permission enforced?**

Test endpoints directly without relying on UI restrictions.

For every submitted object ID ask:

> **What happens if the user changes this to another valid record?**

Verify ownership and permissions server-side.

Admin URLs, hidden buttons, POST requests, and obscure endpoints are not authorization.

## SQL Injection

Inspect every query influenced by request data.

Use prepared statements for values.

For dynamic SQL identifiers such as:

- sort fields;
- column names;
- sort direction;

use explicit allowlists.

Do not rely on manual escaping, quote stripping, or attack-pattern filtering.

## XSS & Output Safety

Treat stored and reflected user-controlled content as unsafe.

Encode output for its actual context:

- HTML text;
- attributes;
- URLs;
- JSON;
- JavaScript.

Pay particular attention to stored content visible to admins or other users.

Do not create one generic "sanitize everything" function.

## CSRF

Protect consequential browser-authenticated actions where appropriate.

Examples:

- profile changes;
- password/email changes;
- deletion;
- purchases;
- moderation;
- admin actions;
- settings updates.

Use a consistent server-validated CSRF mechanism.

Do not rely solely on SameSite cookies, referrer checks, or JavaScript.

## Input Validation

Validate server-side:

- type;
- shape;
- length;
- range;
- enum values;
- ownership;
- required fields.

Handle unexpected arrays, nulls, malformed IDs, extreme values, and duplicate submissions safely.

Use explicit allowed-field lists for creates/updates.

Never mass-assign arbitrary submitted fields into database columns.

## File Security

If uploads/downloads exist, inspect:

- file type;
- size;
- filename;
- storage path;
- public accessibility;
- execution risk;
- ownership;
- download authorization.

Do not trust browser MIME type or original filename.

Prevent traversal and executable uploads.

Do not allow arbitrary request paths to reach `include`, `require`, file reads, or downloads.

## Redirects & URLs

Inspect user-controlled redirect destinations.

Prefer known internal destinations or strict allowlists.

Do not allow arbitrary open redirects without deliberate product need.

If the server fetches user-provided URLs, restrict destinations according to actual functionality.

## Secrets & Production Exposure

Search for exposed:

- DB credentials;
- API keys;
- webhook secrets;
- SMTP credentials;
- tokens;
- `.env` files;
- SQL dumps;
- backups;
- logs;
- debug scripts;
- `phpinfo()`;
- development utilities.

Do not expose secrets to browsers or logs unnecessarily.

Production users should not see raw SQL errors, stack traces, filesystem paths, or internal configuration.

## Abuse Resistance

Inspect endpoints that attackers can automate cheaply:

- login;
- registration;
- password reset;
- contact forms;
- comments/messages;
- uploads;
- search;
- APIs;
- exports;
- email-triggering actions.

Add proportionate protection where justified.

Consider:

- IP/account/session limits;
- request bounds;
- cooldowns;
- pagination caps;
- duplicate-request handling.

Do not apply one arbitrary global limit to everything.

## Duplicate / Replay Safety

For consequential actions ask:

> **What happens if this request is sent twice?**

Especially inspect:

- purchases;
- rewards;
- invitations;
- password reset;
- destructive actions;
- webhooks.

Prevent repeated requests from multiplying effects unintentionally.

## Webhooks & APIs

If present, inspect:

- authentication;
- signatures;
- secret handling;
- replay;
- duplicate events;
- payload validation;
- ownership;
- response leakage.

Do not trust URL secrecy or client-supplied identity.

## Security Headers

Review existing headers and apply appropriate protections where compatible, such as:

- Content-Type;
- X-Content-Type-Options;
- frame restrictions;
- Referrer-Policy;
- CSP where practical;
- HSTS when HTTPS deployment justifies it.

Do not paste a giant generic header policy that breaks the application.

## Pattern Hunt

When one issue is found, search equivalent code.

Examples:

- one missing ownership check → inspect similar endpoints;
- one raw SQL query → inspect dynamic-query siblings;
- one unescaped username → inspect other user content;
- one missing CSRF check → inspect other mutations;
- one unsafe upload → inspect other upload handlers.

Fix the defect pattern where justified.

## Implementation Standard

For every meaningful finding:

1. identify the endpoint or surface;
2. identify the attacker/requester;
3. establish expected permission;
4. reproduce or prove the failure;
5. identify root cause;
6. implement the smallest robust fix;
7. verify the malicious path fails;
8. verify legitimate behavior still works;
9. inspect sibling code;
10. add focused regression coverage where practical.

## Productive Loop

After each wave ask:

- What is now the easiest meaningful way to abuse the site?
- Which endpoint trusts the browser too much?
- Which object can be accessed by changing an ID?
- Which mutation lacks authorization or CSRF?
- Which SQL path remains unsafe?
- Which user-controlled value is rendered unsafely?
- Which upload/download path trusts filenames or paths?
- Which secret/debug detail leaks?
- Which endpoint can be automated cheaply?
- Did a fix break legitimate behavior?

Continue while material, safely actionable issues remain.

## Anti-Overengineering

Do not build:

- a framework inside the project;
- a generic policy engine for a few checks;
- custom cryptography;
- giant validation frameworks;
- unnecessary dependencies;
- speculative enterprise security architecture.

Prefer the smallest understandable mechanism that correctly protects the trust boundary.

## Completion

Finish when:

- important routes enforce authentication and authorization;
- obvious IDOR paths are fixed;
- SQL values are parameterized;
- important output is safely encoded;
- consequential browser actions have appropriate CSRF protection;
- sessions use appropriate security practices;
- dangerous upload/path issues are fixed;
- secrets/debug data are not exposed;
- major abuse endpoints have proportionate controls;
- no discovered P0/P1 issue remains without a documented blocker;
- legitimate functionality still works.

## Final Report

Provide:

1. **Overall result**
2. **Critical/high-risk fixes**
3. **Authentication/sessions**
4. **Authorization/IDOR**
5. **SQL/XSS/input safety**
6. **CSRF/request integrity**
7. **Files/uploads/downloads**
8. **Abuse protection**
9. **Production hardening**
10. **Exact validation performed**
11. **Deliberately unchanged behavior**
12. **Remaining risks with severity and next action**

Do not include unnecessary exploit instructions or secrets.

# Final Directive

Think like a defensive security engineer reviewing a hand-built PHP application where every browser-controlled value may be hostile.

Repeatedly ask:

> **Who controls this value?**

> **Who owns this object?**

> **Where is permission actually enforced?**

> **What if the ID changes?**

> **What if the endpoint is called directly?**

> **What if the request happens twice?**

> **What if the input is malformed, oversized, or hostile?**

> **What privileged value is the server trusting that it could derive itself?**

Leave behind the **same website**, but make it substantially harder to exploit, impersonate, tamper with, abuse, or expose protected data through.