Soap API Security

SOAP (Simple Object Access Protocol) operates on a fundamentally different security model than REST. Unlike REST's stateless, resource-oriented approach, SOAP is a protocol with built-in extensibility for security through WS-Security (Web Services Security). This specification adds security capabilities directly to SOAP messages through XML elements, enabling message-level security independent of the transport layer.

Transport Security: SOAP can use HTTPS for encryption in transit, but WS-Security allows end-to-end encryption even when intermediaries are involved. This means the message remains protected throughout its journey, not just between client and server.

Authentication Mechanisms: SOAP supports multiple authentication approaches. WS-Security provides username token profiles, X.509 certificate-based authentication, and SAML assertions for federated identity. Additionally, SOAP headers can carry custom authentication tokens or API keys specific to the service.

Message Integrity: WS-Security includes XML Digital Signatures to ensure message integrity. Any tampering with the message body or headers invalidates the signature, providing tamper detection beyond what HTTPS offers.

Authorization: While SOAP doesn't have built-in authorization, WS-Policy and WS-SecurityPolicy allow services to declare security requirements. The application layer must implement authorization checks based on the authenticated identity and requested operations.

XML External Entity (XXE) Injection: SOAP messages are XML-based, making them vulnerable to XXE attacks. Malicious XML can include external entities that reference local files, internal networks, or external resources. This can lead to sensitive data disclosure, server-side request forgery, or denial of service through entity expansion.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <exampleRequest>
      <data><!ENTITY % xxe SYSTEM "file:///etc/passwd">%xxe;</data>
    </exampleRequest>
  </soapenv:Body>
</soapenv:Envelope>

XML Bomb Attacks: SOAP parsers can be vulnerable to exponential entity expansion attacks. A small XML payload can expand into gigabytes of data, consuming memory and causing denial of service.

WS-Addressing Abuse: SOAP's WS-Addressing extension allows specifying reply-to addresses. Attackers can manipulate these headers to redirect responses to malicious endpoints or internal network addresses, enabling SSRF attacks.

XPath Injection: Many SOAP services use XML databases or XPath queries to process requests. Unsanitized input in SOAP elements can lead to XPath injection, allowing attackers to bypass authentication or access unauthorized data.

Schema Poisoning: SOAP services often validate against XML schemas (XSD). Malicious actors can exploit schema vulnerabilities to bypass validation or trigger unexpected behavior in the XML processor.

Denial of Service via Large Payloads: SOAP messages can be significantly larger than REST requests due to XML verbosity. Without proper size limits, attackers can exhaust server resources with oversized requests.

Disable External Entity Processing: Configure XML parsers to disable external entity resolution and DTD processing. Most modern XML libraries provide secure parsing options.

// Java example
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

Implement Input Validation: Validate all SOAP message contents against strict schemas. Use whitelisting for allowed elements, attributes, and values rather than blacklisting known bad patterns.

Set Size Limits: Configure maximum message sizes, header sizes, and entity expansion limits to prevent DoS attacks. Implement timeouts for XML processing operations.

Secure WS-Security Configuration: When using WS-Security, ensure proper key management, certificate validation, and signature verification. Regularly rotate cryptographic keys and certificates.

Network Segmentation: Place SOAP services behind appropriate network controls. Consider using message-level security even on internal networks to protect against insider threats.

Logging and Monitoring: Implement comprehensive logging of SOAP requests, including headers and authentication attempts. Monitor for unusual patterns like repeated XXE-like payloads or schema manipulation attempts.

Regular Security Testing: Automated security scanning tools like middleBrick can identify SOAP-specific vulnerabilities including XXE, XML bomb vulnerabilities, and improper authentication configurations. The CLI tool allows you to scan SOAP endpoints directly from your terminal with middlebrick scan , making it easy to integrate into your security testing workflow.