A WordPress REST API review should start with the site's intended behavior, not a blanket assumption that every exposed route is a vulnerability. A public article endpoint and a private membership endpoint serve different purposes. The important question is whether each route reveals or changes only what its approved callers should be able to access. A scanner can support that review, but it cannot invent the site's permission model.
This guide follows an imaginary membership publication with public posts, subscriber-only resources, and a small custom plugin. The assessment takes place on an authorized staging copy with synthetic accounts. It focuses on route ownership, permission decisions, and retesting rather than on exploitation. The same planning approach can support a WordPress security review without implying that ApiScanner.com provides a hosted scanning service or a WordPress plugin.
Inventory the routes and their owners
List the route namespaces used by core features, installed plugins, the active theme, and custom code. Record which team or vendor maintains each component and which business workflow depends on it. Do not assume that an unfamiliar namespace is malicious. It may be a legitimate feature whose documentation has not been incorporated into the site's operating notes.
Separate public reading routes from authenticated editing, administrative, and integration routes. Include the HTTP method in the inventory. A route that intentionally exposes a public article through a read operation may require a very different permission decision for an update operation. Keeping only a list of path strings can hide that distinction.
For the membership publication, note the routes used by public readers, subscribers, editors, and administrators. Give custom endpoints an explicit owner and a description of their data. An endpoint returning membership status deserves a different review from one returning a public category label. The inventory should capture those differences before any scanner is configured.
Review custom permission callbacks
The WordPress handbook on custom REST endpoints documents permission_callback and distinguishes routes intended to be public from those requiring a permission check. It also explains that permission callbacks can inspect the request. Use the handbook to review how your custom endpoints express their intended access rules; the mere presence of a callback does not prove that the rule matches your business requirements.
Ask a developer to explain each custom callback in ordinary terms. Which capability is checked? Does the operation require access to a particular record as well as a general role? Is public access deliberate? Record the answer next to the route so the assessor knows what behavior to expect. A scanner warning should lead to this conversation rather than replace it.
Avoid making a route public just to make an integration or test pass. A failure may indicate missing authentication, an incorrect role, or an overly broad test expectation. Resolve the intended behavior first. Otherwise a troubleshooting change can remove the very boundary the assessment was supposed to verify.
Prepare representative staging identities
Create synthetic accounts representing the roles that matter to the publication. Include a public visitor, a subscriber, and an editor, plus any custom membership role that changes access. Record what each account should be allowed to read or modify. Use an administrator only for tests that genuinely require administrative behavior; its success does not demonstrate the experience of a limited user.
Use synthetic resources with known permissions
Create a public post, a private membership resource, and a draft. The exact set depends on the site's requirements. The objective is a small, interpretable test matrix rather than a copy of the production database. Avoid importing real subscriber data merely to make staging look realistic. Assign each resource a known owner and record its publication state before the test begins.
Confirm the authentication mechanism used by each approved test client. A browser session, an application integration, and a command-line tool may need different setup. Treat an authentication failure as missing coverage until it is understood. Repeated unauthorized responses do not establish that every underlying object permission is correct.
Examine the information in responses
For each selected route, identify the fields that the intended caller actually needs. Review public and authenticated responses separately. A response can be correctly accessible while still containing unnecessary information. Conversely, the presence of a public field is not a security defect when publication of that field is an intentional feature.
Check the relationship between list responses and individual-object responses. The publication may correctly hide a private resource from a listing while another path still exposes it. Use only the synthetic records prepared for the assessment, and compare outcomes with the documented rules. Record expected denials and legitimate successes together so the report describes the boundary rather than a collection of isolated status codes.
Consider whether error responses reveal implementation details that are unnecessary for callers. Keep the review concrete: identify the field or message, explain why it is not needed, and propose an appropriate audience. Avoid reproducing sensitive details in widely shared tickets. A sanitized example is usually sufficient for the initial conversation with the component owner.
Review plugins as maintained dependencies
Keep an inventory of plugin versions, sources, owners, and update procedures. This is an operating record, not a claim that every outdated component is exploitable. When a component changes, identify which routes and workflows need retesting. A plugin update that alters permissions should receive a different review from a purely presentational change.
Remove unused functionality through the site's normal change process after checking dependencies. A route may appear unused because its caller runs only occasionally. Confirm with the owner before disabling it. The security goal is an understandable and maintained interface, not the largest possible number of disabled features.
The WordPress and web application guide organizes these questions alongside Django and server concerns. Keep application permissions distinct from the health of the underlying web server. A well-maintained server does not answer whether the custom membership endpoint enforces the correct subscriber boundary.
Scope automated checks around real workflows
Choose scanner behavior that the staging owner has approved. Identify excluded mutations, email-triggering operations, payment flows, and bulk exports. A crawl or active test may interact with features in ways ordinary page browsing does not. Review the selected profile and stop conditions before starting, even when the tool is familiar.
Observe the application during the assessment. Record unusual errors, timeouts, and authentication failures as operational context. Do not keep increasing access until the report becomes green. The purpose is to understand the behavior of the intended roles, not to give the scanner enough privileges to make every request succeed.
Use the beginner API scanner workflow to turn each warning into an evidence-backed review question. A useful finding names the route, method, role, expected behavior, and observed result. It also identifies the component owner and the next action needed to confirm or reject the observation.
Retest without breaking legitimate access
After a repair, repeat the original failing case and a corresponding legitimate case. A subscriber should retain access to their approved resources while being denied content outside the membership boundary. An editor should still be able to complete the editorial workflow that the permission model supports. Blocking everything is not a successful repair of an access-control defect.
Add focused regression tests to the custom plugin or application workflow where practical. Record why each permission exists and which business rule it implements. This context matters when someone later changes roles, subscription plans, or publication states. A test without an explanation can become an obstacle that future maintainers remove without understanding its purpose.
Review the final evidence with the site's owner, not only the person who ran the scanner. They can confirm whether the behavior matches the actual membership model. Close the issue only when the intended behavior is demonstrated and the remaining limitations are documented.
Conclusion: test the site's permission model
A useful WordPress API security checklist connects route ownership, custom permissions, representative accounts, response content, and regression evidence. It does not confuse public content with a defect or administrator access with comprehensive coverage. Start with a small authorized staging assessment and make the expected behavior explicit. That approach produces repairs the publication can maintain instead of a report whose warnings nobody can confidently interpret.
