🔒 OWASP API Security Training

SOAP VS REST APIs

Important Note: SOAP and REST are often compared, but this comparison isn't entirely accurate since SOAP is a protocol while REST is an architectural style. Understanding their fundamental differences is crucial for API security testing.

📋 Overview

This comprehensive guide explores the key differences between SOAP and REST APIs, their security implications, and their practical applications in modern systems. Understanding these differences is essential for proper API security testing and vulnerability assessment.

🧼 SOAP (Simple Object Access Protocol)

Key Characteristics

Protocol Type: Access Protocol (not just an architectural style)
Message Format: Always XML-based messaging protocol
Protocol Independence: Can work over SMTP, FTP, HTTP, and other protocols
Error Handling: Built-in error handling mechanisms
State Management: Supports stateful operations by default
Compliance: ACID compliance support for enterprise applications

SOAP Request Example

            POST /InStock HTTP/1.1
            Host: example.org
            Content-Type: application/soap+xml
            Content-Length: [length]

            <?xml version="1.0"?>
            <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
            <soap:Header>
            <Authentication>
            <Username>user123</Username>
            <Password>pass456</Password>
            </Authentication>
            </soap:Header>
            <soap:Body>
            <GetStockPrice>
            <StockName>AAPL</StockName>
            </GetStockPrice>
            </soap:Body>
            </soap:Envelope>
        

SOAP Response Example

            <?xml version="1.0"?>
            <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
            <soap:Body>
            <GetStockPriceResponse>
            <Price>150.25</Price>
            <Currency>USD</Currency>
            </GetStockPriceResponse>
            </soap:Body>
            </soap:Envelope>
        

SOAP Components

Envelope: The root element that defines the XML document as a SOAP message
Header: Contains authentication details, session information, and metadata
Body: Contains the actual request and response data
Fault: Provides error handling information when problems occur

🔄 REST (Representational State Transfer)

Key Characteristics

Architecture Type: Architectural style (not a protocol)
Message Format: Can use JSON, XML, HTML, plain text
Protocol: Always uses HTTP/HTTPS methods
State Management: Stateless interactions (no session state stored on server)
Client-Server Architecture: Clear separation between client and server
Cacheable: Responses can be cached for improved performance
Layered System: Architecture can be composed of multiple layers
Uniform Interface: Standardized way of communicating

REST Request Example

            POST /api/products HTTP/1.1
            Host: api.example.com
            Content-Type: application/json
            Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

            {
            "productName": "Laptop",
            "price": 999.99,
            "category": "Electronics"
            }
        

REST Response Example

            HTTP/1.1 201 Created
            Content-Type: application/json

            {
            "id": 12345,
            "productName": "Laptop",
            "price": 999.99,
            "category": "Electronics",
            "createdAt": "2026-03-12T10:30:00Z"
            }
        

REST Components

Resources: Identified by URIs (Uniform Resource Identifiers)
HTTP Methods: GET (read), POST (create), PUT (update), DELETE (remove)
Status Codes: Standard HTTP status codes (200, 404, 500, etc.)
Response Format: MIME types (application/json, application/xml, etc.)
Headers: Contain metadata, authentication tokens, content type

⚖️ Key Differences Comparison

Aspect	SOAP	REST
Type	Protocol	Architectural Style
Communication Method	Service Operations	CRUD Operations (Create, Read, Update, Delete)
Message Format	XML only	JSON, XML, HTML, plain text
State Management	Can be stateful or stateless	Always stateless
Error Handling	Built-in (SOAP Fault element)	Standard HTTP status codes
Protocol Support	HTTP, SMTP, FTP, etc.	HTTP/HTTPS only
Performance	Slower (XML parsing overhead)	Faster (lightweight, especially with JSON)
Ease of Use	More complex, requires tools	Simple, can use browser or basic tools
Caching	Not supported by default	Built-in HTTP caching support
Standards	Strict standards (WS-Security, WS-AtomicTransaction)	Flexible, fewer standards

📊 API Communication Flow Diagrams

SOAP Communication Flow

Client

→

SOAP Envelope (XML)

→

Server

→

SOAP Response (XML)

→

Client

REST Communication Flow

Client

→

HTTP Request (JSON/XML)

→

Server

→

HTTP Response + Status

→

Client

🎯 Use Cases and Applications

SOAP - Best Used For:

Legacy Systems: Financial institutions, banking systems, payment gateways
Enterprise Applications: Where ACID compliance is required
High Security Requirements: WS-Security standards implementation
Formal Contracts: When WSDL (Web Services Description Language) is needed
Stateful Operations: Applications requiring transaction management

REST - Best Used For:

Modern Web Applications: Single Page Applications (SPAs), progressive web apps
Mobile Applications: iOS, Android apps requiring lightweight communication
Public APIs: Third-party integrations, developer-friendly interfaces
Microservices Architecture: Service-to-service communication
IoT Devices: Lightweight protocol requirements

🔐 Security Implications

⚠️ Common Security Vulnerabilities

Both SOAP and REST APIs share several security challenges that must be addressed:

SOAP Security Considerations

Authentication in Headers: Credentials passed in SOAP headers can be intercepted if not using HTTPS
XML Injection: Vulnerable to XML-based attacks if input validation is weak
WS-Security: Provides encryption, signatures, but adds complexity
WSDL Disclosure: Exposed WSDL files can reveal API structure to attackers
XML External Entity (XXE): Can lead to server-side request forgery or data disclosure

Common SOAP Security Commands

wsdler.py -u http://target.com/service?wsdl

soapui -Dfile.encoding=UTF-8 -jar soapui.jar

curl -X POST -H "Content-Type: text/xml" -d @soap_request.xml http://target.com/service

REST Security Considerations

Authentication Tokens: JWT tokens, API keys passed in headers can be intercepted over HTTP
Injection Attacks: SQL injection, NoSQL injection through parameters
Broken Object Level Authorization (BOLA): Accessing resources without proper authorization
Excessive Data Exposure: API returns more data than necessary
Rate Limiting: Missing or improper rate limiting can lead to DoS
CORS Misconfiguration: Cross-Origin Resource Sharing issues

Common REST Security Testing Commands

curl -X GET "http://api.target.com/users" -H "Authorization: Bearer TOKEN"

curl -X POST "http://api.target.com/users" -H "Content-Type: application/json" -d '{"username":"test","password":"test123"}'

curl -X PUT "http://api.target.com/users/123" -H "Authorization: Bearer TOKEN" -d '{"email":"[email protected]"}'

curl -X DELETE "http://api.target.com/users/123" -H "Authorization: Bearer TOKEN"

ffuf -u http://api.target.com/FUZZ -w wordlist.txt -H "Authorization: Bearer TOKEN"

wfuzz -c -z file,wordlist.txt http://api.target.com/api/FUZZ

postman newman run collection.json --environment env.json

Security Testing with Burp Suite

java -jar burpsuite.jar

Configure proxy settings: 127.0.0.1:8080, then intercept and modify API requests

🔒 Best Practices for Both

Always Use HTTPS/TLS: Encrypt all communication to prevent eavesdropping
Implement Strong Authentication: OAuth 2.0, JWT with proper validation
Input Validation: Sanitize all user inputs to prevent injection attacks
Rate Limiting: Prevent brute force and DoS attacks
Logging and Monitoring: Track suspicious activities and anomalies
API Versioning: Properly manage API versions to avoid breaking changes

🚀 Modern Alternatives

GraphQL

A query language for APIs that allows clients to request exactly the data they need. Provides a single endpoint with flexible queries.

curl -X POST http://api.target.com/graphql -H "Content-Type: application/json" -d '{"query":"{ users { id name email } }"}'

gRPC (Google Remote Procedure Call)

High-performance RPC framework using HTTP/2 and Protocol Buffers. Excellent for microservices communication.

grpcurl -plaintext -d '{"name":"John"}' localhost:50051 user.UserService/GetUser

🎓 Practical API Security Testing Workflow

Step 1: Reconnaissance

nmap -p 80,443,8080 -sV target.com

nikto -h http://target.com/api

gobuster dir -u http://target.com/api -w wordlist.txt

Step 2: API Documentation Discovery

curl http://target.com/api/swagger.json

curl http://target.com/api/openapi.json

curl http://target.com/api/docs

Step 3: Authentication Testing

curl -X POST http://target.com/api/login -d '{"username":"admin","password":"password"}' -H "Content-Type: application/json"

hydra -l admin -P passwords.txt target.com http-post-form "/api/login:username=^USER^&password=^PASS^:F=incorrect"

Step 4: Authorization Testing (BOLA/IDOR)

curl -X GET http://target.com/api/users/1 -H "Authorization: Bearer TOKEN"

curl -X GET http://target.com/api/users/2 -H "Authorization: Bearer TOKEN"

for i in {1..100}; do curl -s http://target.com/api/users/$i -H "Authorization: Bearer TOKEN"; done

Step 5: Injection Testing

curl -X GET "http://target.com/api/users?id=1' OR '1'='1" -H "Authorization: Bearer TOKEN"

sqlmap -u "http://target.com/api/users?id=1" --batch --cookie="session=TOKEN"

Step 6: Rate Limiting Testing

for i in {1..1000}; do curl -X POST http://target.com/api/login -d '{"username":"test","password":"test"}'; done

ab -n 1000 -c 10 http://target.com/api/endpoint

📝 Conclusion

Key Takeaways:

SOAP is a protocol with strict standards, best for enterprise and legacy systems requiring ACID compliance
REST is an architectural style that's flexible, lightweight, and perfect for modern web and mobile applications
SOAP uses XML exclusively and can work over multiple protocols (HTTP, SMTP, FTP)
REST primarily uses JSON over HTTP/HTTPS with standard methods (GET, POST, PUT, DELETE)
Both have unique security challenges that require proper authentication, encryption, and input validation
Modern alternatives like GraphQL and gRPC are gaining popularity for specific use cases
Proper security testing requires understanding the API architecture and using appropriate tools

Next Steps in API Security:

In the following lessons, we will dive deeper into specific API vulnerabilities including OWASP API Security Top 10, explore GraphQL security in detail, and work with real-life examples and vulnerable APIs to practice exploitation and remediation techniques.