SOAP wraps each call in an XML envelope with a header and a body, and the server routes it to an operation handler based on an action hint and the body's first element. The layered structure, transport metadata, a SOAPAction header, WS-* headers, and a typed body, creates several independent places where routing and authorization can disagree with what the handler actually executes.
The three surfaces#
- SOAPAction spoofing: routing or authorization keyed on the
SOAPActionheader while the body names a different operation, so a request authorized for one action runs another on a shared endpoint. - Header element injection: WS-Addressing, WS-Security, and custom SOAP headers parsed from a partially trusted message, where replay, signature stripping, or
mustUnderstandhandling bugs live in the middleware. - Body parameter injection: body children and wrapped document parameters built from input, where type confusion, duplicate elements, and
xsi:niltricks change how the server unmarshals and authorizes the call.
Why the envelope multiplies the surface#
A REST call has one place that says what it is: the method and path. A SOAP call says it in several, the action header, the body's operation element, and the WS-* headers, and a framework may trust one while executing from another. The envelope is also parsed by a general XML stack, so the raw markup concerns from XML processing apply underneath; the pages here focus on what is specific to SOAP operation binding rather than generic XML parsing. The test is to make the action header, the body operation, and the security headers disagree, and see which one the server believes.