In this article
Write down the permission rules
OWASP’s API Security Top 10 includes broken object, property and function authorization. In practical terms, check who can read a record, which fields they can change and which operations their role permits. Our recommended starting point is a permission matrix: rows for roles, columns for actions, with a clear decision for each. Include the guest, a second customer in another organization and a staff member with fewer permissions.
OWASP — API Security Top 10 (2023)Test the server directly within permission
For a customer portal, a useful authorized test asks whether customer A can obtain customer B’s request by changing an identifier, whether a normal user can call an administrative action and whether a submitted field changes ownership. Use an agreed test environment and representative test records. Keep evidence minimal and restricted. The visible interface may hide an action while the API still accepts it; review both boundaries.
Review responses and resource limits
For each response, list the fields the user actually needs. Inspect successful and error responses for internal notes, unnecessary personal details or implementation information. Agree sensible request sizes, pagination and limits for costly operations. OWASP identifies unrestricted resource consumption as an API risk. Our practical checklist also asks what happens when an integration times out, retries or sends the same event twice.
OWASP — API Security Top 10 (2023)Include the real integrations
Inventory the APIs your application calls, including identity, storage, payments or messaging where applicable. Establish who verifies incoming events and how failures are recorded. Confirm that a user cannot redirect a server-side request to an arbitrary destination. Test the agreed core journey from browser to persistence and back, including a failed provider response. Success at one boundary should not mask failure at the next.
Retest the access decision
The OWASP Web Security Testing Guide is a reference for planning application tests. For your release, assign an owner to each finding and make the expected outcome explicit. Retesting should repeat the original unauthorized request, confirm its rejection and confirm that an authorized user can still complete the task. Record the deployed version and remaining coverage gaps so the report supports a release decision.
OWASP — Web Security Testing GuideTesting requires written authorization and agreed boundaries. A completed assessment describes the tested scope and time; it cannot establish that every vulnerability is absent.
Discuss your project