Check the application. Not just the server.

Start with routes, roles, and owners

For each API operation, record the method, expected caller, affected data, and maintenance owner. Group public reading, authenticated workflows, and administration separately. A legitimate public route is not automatically a defect, and a private route's successful response is not automatically correct.

Prepare synthetic users with meaningfully different permissions. Include two synthetic tenants or owners when isolation is a requirement. Record what each account should be able to do before configuring the assessment.

WordPress REST API review

The WordPress custom-endpoint handbook documents permission_callback and how a route can express its access decision. For custom routes, ask the maintainer to explain the capability and object-level checks in plain language. The existence of a callback alone does not establish that its logic matches the site's membership or editorial model.

Review namespaces introduced by plugins, themes, and custom code. Maintain an owner and update procedure for each component. Check lists, individual resources, and responses intended for different roles. Avoid using only an administrator identity when the relevant behavior belongs to subscribers or editors.

Read the WordPress REST API checklist for a membership-site example and a focused retest approach.

Django API review

Django's security documentation explains protections and their limits, including CSRF handling, query parameterization, and deployment settings. Use documentation matching the deployed version and review intentional exceptions in custom code.

Verify the workspace boundary

Check individual-object routes alongside lists, search results, exports, and background operations within the approved scope. A correct detail route does not establish that an aggregate response uses the same ownership restriction. Keep the expected permitted and denied cases together.

The Django permission-model article develops that test plan using synthetic workspaces and distinct roles.

LAMP servers and deployment controls

For a Linux, Apache, database, and PHP environment, distinguish the web-server boundary from application permissions and database access. Record the deployment owner, application owner, and relevant configuration. A healthy server configuration does not prove that a custom endpoint applies the correct business rule.

Scope scans around excluded mutations, notifications, payment operations, and shared dependencies. A crawl can still issue requests. Keep detailed evidence outside the public web directory and preserve an incomplete status when authentication or connectivity prevents coverage.

Repair behavior, then verify it

Repeat the original failing case after the change, and confirm that a legitimate user retains access to the intended operation. Add a regression test at the layer that best expresses the requirement. Connect the result to the application revision and the security review workflow.

Primary references

Read the documentation that matches your tool, framework, and deployment. These sources provide context; they do not establish coverage of your environment.

• WordPress custom REST endpoints
• Django 5.2 security documentation