A useful audit is not a theater of green tool screens. It means finding what can take down the application or leak data, documenting it with evidence, and prioritizing what to fix first.
This methodology applies to PHP/Laravel, Node.js, and WordPress applications (multisite, Elementor, stores with payments). When there is ecommerce or local gateways, it includes checkout and webhooks — the same surface covered by online payments.
48-hour breakdown
Hours 0–4: attack surface map
- Inventory of public routes (web + API).
- Forms, uploads, payment webhooks, cron endpoints.
- Current headers, cookies, redirects.
- On WordPress: version, child theme, active plugins, administrator users.
- On multisite: sites, super-admins, and network plugins.
Hours 4–16: authentication and session
- Password reset, user enumeration, rate limiting.
Secure/HttpOnly/SameSitecookies.- CSRF on state-changing forms.
- JWT:
exp, rotation, insecure storage inlocalStorage. - WordPress admin or Filament/Horizon exposed without MFA.
Hours 16–32: injection and business logic
- Misused SQL / ORM, stored XSS, path traversal.
- Mass assignment in Laravel (
$fillable/$guarded). - IDOR: can you view order
#id+1? - On payments: confirm the amount is not trusted from the client.
- Uploads: real file type, not just the extension.
Hours 32–48: dependencies and deliverable
composer/npm auditwith judgment.- Abandoned WordPress plugins or those with known advisories.
- Secrets in repo, exposed
.env, public backups. - P0/P1/P2 report + remediation plan by sprint.
Practical checklist
- Are
.env,.git, or backups accessible by URL? - Do login, reset, and sensitive APIs have rate limiting?
- Do session cookies have correct flags on HTTPS?
- Is CSRF active on state-changing forms?
- Do policies/capabilities exist and get called on every route?
- Do uploads validate real MIME types?
- Do payment webhooks validate signature/origin and are idempotent?
- Do security headers (CSP, HSTS) exist without breaking the front end?
- Do critical dependencies have an update owner?
- Can deploy reintroduce the same secret or old plugin?
Laravel: review points
- Validation with Form Requests on all API inputs.
- Authorization: Policies/Gates on show/update/destroy.
- Mass assignment: models with
$guarded = []or dangerous fillables. - Files: private
Storagedisk; signed URLs. - Queues with backoff and dead-letter; payloads without unnecessary PII.
APP_DEBUG=falsein prod; Telescope/Horizon not public.
WordPress: review points
- Remove generic
adminuser; review roles; 2FA on privileged accounts. - XML-RPC: disable if no legitimate app needs it.
- REST: user endpoints that leak information.
- Uploads: execution blocked in
uploads. - WooCommerce: updated gateway plugins; webhooks with minimum permissions.
Deliverable format
| Priority | Criteria | Example |
|---|---|---|
| P0 | Exploitable now / high impact | RCE, SQLi, manipulable payment, public .env |
| P1 | High risk | Stored XSS, order IDOR, CSRF on sensitive actions |
| P2 | Hardening | Incomplete headers, old plugins not yet exposed |
Each finding includes: where, how to reproduce, risk, suggested fix, and relative effort. Connects with DevOps and Coolify, and cybersecurity .