# Troubleshooting and security

Diagnose delivery, permissions, cleanup, and operational boundaries.

Diagnose delivery, permissions, cleanup, and operational boundaries.

## How it works

*   Cybermaps administration pages require `manage_options`; multisite network settings require `manage_network_options`.
*   Setting saves and state-changing admin actions use WordPress nonces and capability checks.
*   Private REST reads compare `X-Cybermaps-Secret` with `hash_equals()` and send private, non-cacheable responses.
*   Protected Varnish PURGE requests are disabled until configured and are limited to exact Cybermaps publication URLs.
*   Report, analytics, and configuration exports require authorization and use explicit content types and filenames, no-cache headers, and `X-Content-Type-Options: nosniff`. Downloadable formats use attachment disposition; printable report HTML is served inline.
*   CSV exports protect spreadsheet-leading formula characters and use UTF-8 output.
*   Configuration imports are size-bounded, parsed before writes, sanitized by their owning configuration group, verified after writes, and rolled back on a failed verification.
*   Cybermaps admin responses restrict framing to the same origin with a `Content-Security-Policy: frame-ancestors 'self'` header.
*   Public discovery documents are read-only. The admin REST purge requires `manage_options`; the optional MCP operations mode exposes a separately authenticated and capability-checked purge tool. Filesystem changes remain ownership-verified.

## LLMS build responses

HTTP 503 with `Retry-After: 5` indicates a busy or unfinished generation; retry after the stated delay. HTTP 507 with `publication_too_large` indicates an output-size or PHP memory-headroom limit. Neither response is a completed publication. See [AI publishing](https://cybermaps.dev/docs/machine-publications/) for the limits and the distinction between a cooperative deadline and a blocked backend.