A web service accepts requests from other software and returns data or performs an action. Its security depends on the decisions made along that path: who may call it, which records they may use, how input is interpreted and how much work a request can trigger.
SOAP services often use XML and publish a WSDL description of their interface. Modern APIs may use different formats, but the review still begins with the service's purpose and trust boundaries. An interface description helps a client communicate; the application must enforce the permissions behind it.
Map one complete request
Choose an important operation, such as reading an invoice or submitting an order. Identify the caller, authentication method, requested record, downstream services and returned fields. Include administrative operations and background jobs. Record an accountable owner for each boundary.
Separate transport protection from business permission. A secure connection protects communication; the service still needs to decide whether this caller can perform this action on this particular record. OWASP’s web-service guidance treats authorization, input validation and availability as distinct controls. That separation makes a review more precise than asking whether the service is “behind a firewall.”
Check permissions at the operation and record
Define the allowed relationship between a user and the data: their own order, an assigned customer, or a documented administrative role. Apply that relationship when the request is processed. A record identifier supplied by the client is a request for access, not proof of permission.
Use authorized tests with fictional records in a controlled environment. Verify that one ordinary account can read its permitted record and is denied another account's record. Check the actual response fields as well as the status. A successful denial should leave no unauthorized content in a response or log visible to that user.
Treat parsing and validation as separate jobs
For XML, identify the actual parser, library version and enabled features. External entities can cause a processor to retrieve outside resources. OWASP’s parser-specific XXE guidance recommends disabling DTDs where possible; applications that require them need explicit restrictions on external resolution and related resource access. Defaults differ across libraries.
Schema validation checks structure and permitted values. It complements parser hardening and application rules: a correctly formed order can still refer to the wrong customer or request an unacceptable quantity. Record what the service does when a security setting is unsupported. Treat that as a configuration problem to fix before processing untrusted input.
Bound the work a request can create
Set limits appropriate to the operation: request size, processing time, concurrent jobs and downstream work. A small input can trigger an expensive report. Review retries and queued jobs as well as the public endpoint. OWASP’s REST guidance covers request validation, size limits, access control and safe error handling.
| Boundary | Evidence to request |
|---|---|
| Access | A permitted and denied test for the same operation, with fictional accounts and records. |
| Parsing | The deployed parser version and effective settings for external resource access. |
| Work limits | Observed behavior when a documented limit is reached, including queued work. |
| Operations | An owner, useful event records and a response route for repeated failures. |
Keep logs useful without copying secrets or whole sensitive payloads. A request reference, time, operation, decision and responsible service often make a better troubleshooting record than unrestricted request bodies.
Fictional example: an invoice export
A supplier portal requires login but accepts a customer number in an export request. The review asks two separate questions: does the account belong to that customer, and can the export consume excessive resources? The team creates fictional customer records, confirms cross-customer access is denied, and checks that a large export follows a bounded job process.
The resulting record names the control, the observed result and the owner of any gap. “Login works” would have answered only the first step of the review.
Repeat the relevant checks when authentication, parsing libraries, service dependencies or data-access rules change. Use the downloadable review sheet to record evidence and unresolved questions.