# CSRF Route Audit

Audit date: 2026-07-26

> Phase 1 is audit-only. No CSRF middleware was added, removed, or reordered.

## Method

The audit inspected the live Express router stacks for dashboard admin, dashboard auth,
and webview routes. Every `POST`, `PUT`, `PATCH`, and `DELETE` route was classified by
whether `csrfProtection` appears in its middleware chain. Multipart ordering, the global
CSRF error handler, cookie options, and external webhook authentication were also
checked in source.

## Coverage

| Router | Mutation routes | With `csrfProtection` | Without |
|---|---:|---:|---:|
| Dashboard admin | 145 | 58 | 87 |
| Dashboard auth | 4 | 1 | 3 |
| Webview | 6 | 3 | 3 |
| **Total** | **155** | **62** | **93** |

The audit counts route registrations, not unique paths. It does not prove that every
protected route's client submits a valid token.

## Findings

### High Risk

1. **Eighty-seven dashboard-admin mutations have no CSRF middleware.** Representative
   groups include client/provider administration, deletes and status toggles, settings
   changes, attributes, packages, locations, products, advertisements, and auctions.
2. **Dashboard auth has three unprotected mutations:** `POST /changePassword`,
   `DELETE /logout`, and `POST /remove-account`.
3. **`POST /web/checkout` is an unprotected state-changing payment flow.**
4. **OTO webhooks are unprotected by CSRF, as expected for third-party callbacks, but
   no inbound signature or shared-secret validation was found** for
   `POST /web/webhooks/oto` or `POST /web/webhooks/oto-delivered`. These routes need an
   explicitly approved webhook-authentication design, not browser CSRF tokens.

### Middleware and Ordering

- Two multipart routes put `csrfProtection` before `uploadsFiles()`:
  `POST /dashboard/infoServices/create` and
  `POST /dashboard/infoServices/edit/:id`. In this project the upload parser must run
  first so a multipart `_csrf` field is available.
- Many protected mutations validate input or perform middleware work before checking
  CSRF. Token verification should normally occur as early as request parsing permits.
- `src/middlewares/csrfTokens.js` targets
  `views/admin/505Page/error-505.html`, but only the EJS view exists. For non-CSRF
  errors the four-argument middleware calls `next()` without forwarding the error,
  which can swallow an unrelated upstream error.
- CSRF cookies are configured with `httpOnly: false` and `secure: false`, with no
  explicit `sameSite`. Deployment and browser requirements must be reviewed before
  tightening these values.

## Representative Unprotected Dashboard Areas

- `/supervisions/delete`, `/supervisions/blockUnBlock`,
  `/supervisions/activateDeactivate`
- client create/edit/delete and subscription mutations
- provider delete/status mutations and `/providersMeta/action/:id`
- terms/about and other settings edits
- attribute, package, country, city, product, advertisement, and auction mutations

The complete result is reproducible by inspecting each router layer and checking
mutation-route handler names for `csrfProtection`.

## Recommended Follow-up (Requires Approval)

1. Define explicit exemptions and authentication requirements for third-party webhooks.
2. Repair the CSRF error handler without enabling new route enforcement.
3. Correct the two multipart middleware-order defects.
4. Pilot enforcement on high-risk dashboard authentication and settings mutations,
   with EJS/AJAX regression tests.
5. Expand by route group only after the pilot and document cookie-policy changes.

No recommendation above has been implemented in Phase 1.