Inspect the complete route surface
Review route definitions, lazy-import tables, generated manifests and service-worker precache lists in the release. Include routes available only after a feature flag, an account change or a particular navigation sequence. A screen does not become private because the homepage does not link to it.
Some route names are harmless public implementation details. Others can reveal internal workflows or accidental diagnostics. Classify what is intentionally public, remove unused development screens from production builds and keep privileged data out of static route files.
Separate screen access from operation access
A browser-side route guard can improve the experience by redirecting a signed-out user. The server must still authenticate and authorize every sensitive operation. Test an API call independently of the route guard, using the same controlled actor/resource matrix you use elsewhere in the backend.
For example, hiding an administration page does not protect an export endpoint. The handler should check the current user’s role, permitted tenant and export scope even if the caller never downloaded the administration page.
Review static and cached data
Search the public artifact for fixture datasets, internal sample responses and embedded configuration that a route imports. Confirm that a static JSON file is appropriate for every visitor who can fetch it. A page can have strong API authorization while a forgotten public data export bypasses that boundary.
Inspect service-worker and CDN behavior after removing a route. A new application version may stop linking an old chunk while the old file remains reachable or cached. Decide how long historical assets stay public and whether any sensitive content was ever included.
Validate both delivery and denial
After a production-style build, test legitimate navigation, lazy-loading and expected redirects. Then request the relevant asset paths and backend operations without relying on UI state. Confirm that a client-visible route name never acts as the only secret protecting a privileged function.
CloneGuard audits supported release files and flags some known exposures. It does not infer every route’s intended audience or prove all route guards correct. Keep a route inventory and request-level access tests with the release evidence, especially when experimenting with code splitting or asset cleanup.
Use a release removal checklist for internal screens
When retiring an internal debug screen, remove its production route registration and check that its data fixtures are no longer imported elsewhere. Inspect the completed chunk inventory instead of assuming tree shaking removed the code. If an older public deployment contained sensitive data, evaluate that as historical exposure rather than declaring success because the current navigation is clean. Then verify the legitimate screen that shared components with the removed route still works. A targeted removal should reduce unwanted publication without breaking another workflow or leaving the original backend action publicly callable.
Practical checklist
- List route manifests, lazy chunks and precache entries.
- Remove development routes and public fixture data.
- Authorize backend actions independently of route guards.
- Inspect old asset URLs after route removal.
Sources and further reading
Primary references support the technical details. Procedures here are guidance; only explicitly recorded project results describe tests we ran.
Prepared with AI assistance. How this library is produced. Suggest a correction; keep private code and credentials out of public issues.