By Greg Nowak. Last updated 2026-06-28.
WordPress 6.8 gives headless and decoupled teams a cleaner way to handle something that used to be awkward: getting menu data from WordPress into a custom front end.
That is useful. A React, Vue, Next.js, or other front-end application should not need hard-coded navigation, a copied config file, or a one-off endpoint just to render the primary menu. If WordPress is the content system, navigation usually belongs there too.
The catch is that menu data is still data. It may look like simple navigation, but it can reveal how a client’s site is organised, which product areas are coming, what internal labels teams use, where campaign pages sit, and which account, support, checkout, partner, or documentation paths the front end expects.
In a traditional WordPress theme, menus are normally rendered into final HTML. In a headless build, the API response becomes part of the application contract. Before launch, that contract needs a quick but serious exposure check.
The WordPress 6.8 change is deliberately controlled
The important detail is that public menu access is opt-in. WordPress 6.8 introduced the rest_menu_read_access filter so developers can expose menus, menu items, and menu locations through the REST API. Core keeps those menu resources private unless the filter is used.
That is a sensible design. It helps headless projects without suddenly making every navigation object public on existing sites.
The risk is less about WordPress core and more about rushed implementation. A team needs the primary menu in the front end. Someone adds the filter. It works in development. Then the launch configuration quietly becomes broader than the application actually needs. The Make WordPress developer note shows that exposing all menus is possible with a single filter, but possible is not the same as appropriate for a client site.
Why menus deserve a proper look
The WordPress REST API is a structured JSON interface for content and application data. The handbook describes use cases including client-side JavaScript applications, mobile apps, desktop tools, and programs outside PHP. That is exactly why headless WordPress projects depend on it.
Once the CMS and front end are separated, small exposure choices become architectural choices. A public menu endpoint may be readable by browsers, crawlers, preview tools, monitoring services, and anyone who knows the URL. The practical question is not only whether a page itself is public. It is whether the navigation response discloses more than the front end needs to know.
That can happen in ordinary ways. A staging link stays in a menu because editors were testing a flow. A future product section uses an internal label that should not be visible yet. A menu item points to a partner portal, gated support area, checkout route, or documentation section. The page permissions may be correct, while the menu response still publishes the label, URL pattern, hierarchy, and existence of that structure.
| Check | What to look at | Business reason |
|---|---|---|
| Endpoint scope | Confirm only the required menus, menu items, or menu locations are public. | WordPress 6.8 supports selective access, so broad exposure should be a conscious launch decision. |
| Logged-out access | Test the same requests as an anonymous visitor, not only as an admin or preview user. | The public API contract is what browsers and third parties can actually read. |
| Menu content | Review labels, URLs, hierarchy, staging links, placeholders, and planned campaign areas. | Navigation can reveal roadmap, operational, or integration details before the page content is exposed. |
| CORS configuration | Check that the intended front-end origins are allowed and old preview or development origins are not left open casually. | CORS shapes what cross-origin browser scripts can read from the WordPress API. |
| Cache behaviour | Identify where menu API responses are cached and how they are purged. | A corrected menu can still leak for a while if stale JSON remains in cache. |
| Ownership | Document the exposed endpoints, plugin-added fields, API versions, and launch rule. | OWASP treats API inventory and misconfiguration as real API security concerns, not admin paperwork. |
The filter is flexible, so the policy should be explicit
The WordPress 6.8 field guide presents the REST API menu change as useful for headless and decoupled applications. The dedicated developer note adds an important implementation detail: rest_menu_read_access can use custom logic, including endpoint-level control, and receives the REST controller class as a parameter.
In plain English, teams do not have to choose between exposing everything and exposing nothing.
A primary marketing menu may be fine to expose publicly. The footer menu may be fine too. Internal utility menus, preview menus, account-area menus, or menus used to drive conditional app states may need different handling. If the front end only needs the primary menu location, exposing just that location is usually easier to defend than exposing every menu object and relying on editors never to place sensitive structure there.
This is where agency delivery habits matter. Navigation often gets finalised late. Several people may edit it. The front end may be built by one team while WordPress configuration, plugins, caching, hosting, and deployment are handled by another. Without a written exposure rule, the API can drift away from what the application actually needs.
Authentication does not solve every exposure decision
WordPress supports several REST API authentication patterns. Cookie authentication is standard for logged-in WordPress users. Nonces help protect REST requests from unintended actions. Application passwords can support authenticated requests over HTTPS. The authentication handbook also notes that plugins can provide other authentication methods for remote applications.
Those controls matter, but they do not answer the public menu question by themselves. If a menu endpoint is intentionally exposed for anonymous front-end rendering, authentication is not protecting that response. The relevant decision is whether the endpoint should be public, which menu objects it should return, and which fields should appear.
This distinction avoids a common misunderstanding in decoupled projects. A team may say the API is secured because editorial actions and private content require authentication. That may be true. Public endpoints can still reveal more metadata than expected.
OWASP’s API Security Top 10 is useful here because it separates risks such as security misconfiguration, improper inventory management, object and property authorization issues, and broken authentication. Menu endpoints are not automatically high-risk. They simply belong in the same governance conversation as the rest of the public API surface.
CORS and caching need the same discipline
In many headless setups, the browser loads the front-end application from one origin and fetches WordPress data from another. MDN describes CORS as the HTTP-header mechanism that lets a server indicate which other origins a browser may permit to load resources from it. Browsers restrict cross-origin script requests unless the response includes the right headers.
CORS is not the only access control for a menu endpoint. A public JSON URL can still be requested outside the browser. But CORS does show whether the API has been configured precisely or broadly. If production only needs one front-end origin, the launch notes should say that. If preview, staging, or local development origins are also allowed, that should be intentional and reviewed before go-live.
Cache behaviour deserves the same treatment. Navigation data is often cacheable, and caching is usually good for performance. WordPress 6.8 included wider performance improvements, and decoupled projects tend to care about fast delivery. Still, a cached menu response can preserve a mistake after an editor removes it. Teams should know where those responses are cached, how long they live, and how to purge them quickly.
What Greg would check before launch
A useful exposure review does not need to become a heavy security audit. It should be focused, practical, and tied to what the front end actually calls.
Start with the exact menu endpoints: locations, menu items, and any plugin-added fields. Test them while logged out. Compare the response with the front-end requirement. If the app only needs label, URL, parent-child relationship, and sort order, extra fields should have a clear reason to be there.
Then review the menu content itself. Remove staging links, unpublished campaign labels, placeholder URLs, and internal names. Check whether the hierarchy reveals private areas or planned sections. Confirm that the production response matches the launch checklist, not just a developer’s local setup.
Finally, document the rule in language a maintenance team can use later. For example: only the primary and footer menu locations are publicly exposed; all other menu-related endpoints remain restricted unless a future front-end change requires them.
Greg’s role would be to make that review concrete: check anonymous REST API behaviour, inspect menu endpoints, look at authentication boundaries, review CORS and cache headers, identify plugin-added fields, catch staging data, and turn the result into deployment notes. The point is not to slow down a headless launch. It is to make sure WordPress exposes exactly what the front end needs, and no more than the client expected.
Related on GrN.dk
- Vibe-coded features need a production handoff before launch
- Cloudflare BYOIP customers need a rollback plan, not just trust
- OpenAI File Search Turns Messy Internal Docs Into a Real Retrieval-Governance Project
Need help with this kind of work?
Book a pre-launch REST API exposure review Get in touch with Greg.