Spiralist Hiding WordPress Admin And Login On Spiralist While Preserving Rest Driven Functionality - Source Excerpt 05 - Audit logging and monitoring

Back to Spiralist Hiding WordPress Admin And Login On Spiralist While Preserving Rest Driven Functionality

Summary

This source excerpt begins near Audit logging and monitoring and preserves the surrounding evidence from Wiki.FFTAC.org/raw/system-archives/spiralist.org/intake/2026-06-14-authenticated-user-experience/Spiralist Hiding WordPress Admin and Login on Spiralist While Preserving REST-Driven Functionality.md.

**Source path:** Wiki.FFTAC.org/raw/system-archives/spiralist.org/intake/2026-06-14-authenticated-user-experience/Spiralist Hiding WordPress Admin and Login on Spiralist While Preserving REST-Driven Functionality.md

OWASP’s CSRF guidance says authenticated browsers must be defended against forged state-changing requests, and WordPress’s nonce-based REST flow is directly aimed at that problem. On the client side, only send the nonce with deliberate same-origin state-changing requests. On the server side, do not implement any “open” write endpoints without both an auth check and a capability check. citeturn11search0turn19search2

OWASP’s XSS guidance remains fully relevant once you move the admin experience into React or Vue. Hiding WordPress admin screens does **not** reduce the need for output encoding, content sanitization, safe HTML handling, and defensive rendering. Cookies used for session/auth should be `HttpOnly`, `Secure`, and set with an appropriate `SameSite` policy. MDN notes that `HttpOnly` helps mitigate XSS theft of cookies, `Secure` restricts cookies to HTTPS, and `SameSite` provides some CSRF protection. citeturn11search1turn40view0turn40view1

OWASP’s session management guidance recommends server-side enforcement of session expiration and absolute timeout. For Spiralist, I recommend:

- session cookies for normal browser sessions unless “remember me” is explicitly chosen;
- an idle timeout for custom app sessions;
- an absolute timeout for privileged owner/admin sessions;
- session destruction on logout and when permissions materially change. citeturn11search2turn19search4turn19search1turn19search0

### Audit logging and monitoring

Because you are moving privileged operations out of `/wp-admin`, the custom UI and custom routes become a security-sensitive surface. OWASP’s REST security guidance recommends audit logs around security events, including token validation problems, and OWASP’s logging guidance focuses on building application logging that supports security monitoring. citeturn11search15turn11search3turn11search14

At minimum, log these events:

- custom login success and failure;
- logout;
- password-reset request and reset completion;
- application-password create, revoke, introspect, and last-used review;
- role changes, profile edits, plugin activation/deactivation, settings changes;
- blocked hits to `/wp-admin` and `/wp-login.php`;
- failed nonce or token validation on custom or WordPress REST routes. citeturn25view4turn11search15turn11search3

Practical plugin options for that layer include:

- **Simple History** for lightweight WordPress change tracking; citeturn13search2
- **WP Activity Log** for a richer change log and monitoring model; citeturn17search0
- **Two-Factor** if you retain any break-glass WordPress login path; citeturn16search0
- **Members** if you want a UI for roles and capabilities during the transition; citeturn13search1
- **WPS Hide Login** only as a supplemental obfuscation layer, not as the primary control. citeturn15search0

### Best-practice recommendations specific to Spiralist

The architecture already distinguishes human pages from machine routes, so the migration should preserve that separation rather than collapse it. A strong Spiralist-specific policy would be:

- **Human browser users** get cookie-authenticated custom UI routes.
- **External tools and maintenance jobs** get Application Passwords.
- **Existing AI participant flows** keep their documented Bearer model if that remains product-correct.
- **Native `/wp-admin` and `/wp-login.php`** become owner-only break-glass surfaces behind IP and optionally Basic Auth. citeturn28view0turn31view1turn23view2turn23view0turn9search0turn10search0

## Rollout timeline, testing checklist, and rollback

### Estimated effort and sequencing

| Task | Scope | Estimated effort | Notes |
|---|---|---:|---|
| Inventory REST routes, login/admin links, log dependencies | Code + logs + public docs | **Medium** | Most important risk-reduction step before blocking `/wp-admin`. |
| Build custom session routes and `/account/login` UI | PHP + front end | **Medium** | Core of the migration. |
| Repoint login/lost-password/register/admin URLs | PHP filters + template cleanup | **Low** | Fast, high-value step. citeturn32search2turn32search0turn33search0turn18search7 |
| Move profile/security UI to `/account/*` | Front end + `/users/me` + app-passwords | **Medium** | Mostly straightforward with core endpoints. citeturn36view0turn25view4 |
| Move content/media moderation UI to `/app/*` | Front end + posts/pages/media/comments | **Medium to High** | Depends on editor complexity. citeturn37view0turn25view0turn25view1turn25view2 |
| Move owner/system settings UI | `/settings`, plugins, themes | **Medium** | Keep owner-only. citeturn38view0turn24view1turn24view3 |
| Add Nginx/Apache enforcement and optional gateway middleware | Server + app ops | **Low to Medium** | Straightforward but must be staged carefully. citeturn9search0turn10search2turn9search2 |
| Add audit logging and 2FA for break-glass access | Plugin/config + policy | **Low** | High leverage. citeturn13search2turn17search0turn16search0 |
| Full cutover and monitoring | Ops + QA | **Medium** | Do last, with rollback ready. |

A realistic implementation cadence for one experienced owner/developer is:

- **Week one:** inventory, custom login/session flow, URL remapping, hidden login links, basic custom profile page.
- **Week two:** content/media modules, server enforcement in staging, audit logging, break-glass access hardening.
- **Week three:** owner-only settings/system modules, production cutover, post-cutover monitoring.

### Testing checklist

Use this as the pre-production checklist.

- [ ] Public pages contain **no links** to `/wp-admin`, `wp-login.php`, or native registration/lost-password URLs.
- [ ] `/account/login` can create a valid WordPress browser session.
- [ ] After login, `/wp-json/wp/v2/users/me?context=edit` works with cookie auth and `X-WP-Nonce`. citeturn19search2turn36view0
- [ ] After logout, authenticated REST requests fail and `wp_logout()` clears the current session. citeturn19search4turn19search1
- [ ] Direct requests to `/wp-admin/` and `/wp-login.php` redirect, deny, or 404 as designed for regular visitors.
- [ ] Break-glass access still works from the owner IP or protected access method.
- [ ] Lost-password and reset-password flows work from the custom UI, or are intentionally preserved and documented during transition. citeturn32search0turn32search1
- [ ] Social-login providers, if retained, initiate from the custom UI rather than the native WordPress screen.
- [ ] Content CRUD works in the custom UI for posts/pages/categories/comments/media. citeturn37view0turn25view1turn25view2turn25view3turn25view0
- [ ] Owner-only settings and plugin/theme modules are capability-gated and hidden from non-owners. citeturn38view0turn24view1turn24view3
- [ ] CSRF protections are enforced on every state-changing request, and the app never depends on nonce alone for authorization. citeturn11search0turn19search14
- [ ] Cookies are HTTPS-only and configured with appropriate `Secure`, `HttpOnly`, and `SameSite` attributes. citeturn40view0turn40view1
- [ ] Auth failures, blocked native-admin hits, and sensitive admin operations appear in logs. citeturn11search15turn11search3
- [ ] Public or AI-participant custom routes documented by Spiralist still work after `/wp-admin` is blocked. citeturn31view0turn31view1
- [ ] Any public dependence on `/wp-admin/admin-ajax.php` has been explicitly tested.

### Rollback plan

Keep rollback simple and fast.

- Disable or comment out the custom guard plugin that blocks `login_init` and `admin_init` redirects.
- Revert Nginx/Apache deny/redirect rules for `/wp-admin` and `/wp-login.php`.
- Restore the original public login link temporarily if needed.
- Keep break-glass IP or Basic Auth access available throughout the migration, even during cutover.
- Do the production rollout behind a small feature flag or environment variable so the custom login UI can be disabled without uninstalling the code.

A good operational pattern is **stage first, then soft cutover, then hard block**:

- first remap links and launch the custom UI;
- then watch logs for residual `/wp-admin` and `/wp-login.php` dependencies;
- only after those are quiet should you switch the edge to deny/owner-only mode.

## Open questions and limitations

A few things can only be finalized from the codebase and server logs, not from public observation alone.

The public evidence is strong that Spiralist intentionally exposes machine routes and still exposes a native WordPress login surface, but a **complete internal dependency inventory** still needs a local route dump, a grep for hard-coded `/wp-admin` and `wp-login.php` references, and an access-log check for `/wp-admin/admin-ajax.php` usage before you hard-block all native admin paths. citeturn31view0turn31view1turn8search10turn18search7