Welcome to the S4E Create with AI Library
Enterprise-grade Automation with Pentester-level Flexibility
This library showcases real examples of how security teams use S4E Create with AI to save time, reduce manual effort, and strengthen their defenses.
Unlike traditional scanners that limit users to predefined checks, S4E Create with AI gives complete flexibility. You describe what you need, and the AI builds and runs it instantly. This allows teams to automate the exact tests they want instead of being restricted to what the product designer imagined.
Detecting Risky HTTP Method Exposure on Read-Only Endpoints
Problem
API endpoints designed for retrieving data (Read-Only) are expected to support only safe methods like GET. However, due to misconfigured web servers, frameworks, or API gateways, these endpoints sometimes inadvertently accept state-changing methods like POST, PUT, or DELETE. If an endpoint intended only to display user profiles accidentally processes a DELETE request, an attacker could wipe out data simply by changing the HTTP verb. These “shadow methods” are often undocumented but fully functional.
Risk Prevented: Unauthorized data modification, deletion, or creation caused by failing to restrict HTTP methods on read-only resources.
Traditional Approach
Security analysts usually test for this by manually capturing requests in a proxy tool (like Burp Suite) and changing the HTTP method to see what happens. Alternatively, they might check the Allow header in an OPTIONS response, but this header is often unreliable or misconfigured. Testing every single read-only endpoint against every possible state-changing method manually is tedious, repetitive, and unscalable for large API inventories.
How Create with AI Changes
It With S4E Create with AI, you can enforce method restrictions across your entire application inventory in seconds. You define the rule “Read-only endpoints must not accept state changes” and the AI generates a scan that actively attempts to perform POST, PUT, and DELETE requests on your target. It doesn’t just check headers; it verifies if the server actually processes the request (returning a 2xx code), providing definitive proof of the vulnerability.
Instant Solution (Create with AI)
Prompt: Create a scan that detects risky HTTP method exposure on read-only endpoints. The scan should target endpoints normally accessed via GET and attempt to send state-changing requests using POST, PUT, and DELETE methods to the same URLs. If the server responds with any 2xx success status code (e.g., 200, 201, 202, 204) instead of blocking the request (e.g., 405 or 403), raise an alert indicating potential unauthorized state changes; otherwise, report “Methods are properly restricted to GET only.”
The generated scan actively probes your assets, simulating an attacker trying to force a state change, and alerts you only when a request is successfully processed.
🎥 Watch the Scan in Action
The video demonstrates Create with AI generating the script, sending DELETE and POST requests to a standard GET endpoint, and flagging the asset when a 200 OK response is received unexpectedly.
Value
- Validates API Design: Ensures that read-only endpoints are technically enforced, not just documented as such.
- Prevents Accidental Data Loss: Stops attackers from using hidden DELETE methods.
- Reduces False Positives: Flags issues only when the server returns a success code (2xx), ignoring standard errors.
- Scalable Verification: Checks thousands of endpoints for method restrictions instantly.
Closing Takeaway
Just because an HTTP method isn’t in your documentation doesn’t mean your server won’t execute it. Misconfigurations in frameworks often leave default methods enabled. S4E Create with AI turns a complex manual validation task into a simple, continuous automated control, ensuring your read-only data actually stays read-only.
🧰 Check It Yourself
Check the sample scan below or watch the video for a live walkthrough.
from s4e.config import *
from s4e.task import Task
from s4e.utils.commons import http_or_https
class Job(Task):
def run(self):
asset = http_or_https(asset=self.asset, _headers=self.headers, session=self.session)
self.output['detail'] = []
self.output['compact'] = []
self.output['video'] = [f"python3 http_method_restriction_scan.py {asset}"]
methods = ['POST', 'PUT', 'DELETE']
risky_methods = []
try:
for method in methods:
response = self.session.request(method=method, url=asset, headers=self.headers, timeout=self.timeout, verify=False, allow_redirects=False)
self.output['video'].append(f"{asset} - {method}: {response.status_code}")
if 200 <= response.status_code < 300:
risky_methods.append(f"{asset} - {method} ({response.status_code})")
if risky_methods:
self.output['compact'].append("Risky HTTP methods allowed.")
self.output['detail'].append("Risky HTTP methods detected:")
self.output['detail'].extend(risky_methods)
self.output['video'].append("Risky HTTP methods detected.")
else:
self.output['detail'].append("Methods are properly restricted to GET only.")
self.output['video'].append("Methods are properly restricted to GET only.")
except:
self.output['detail'].append("No risky HTTP method exposure detected.")
self.output['video'].append("No risky HTTP method exposure detected.")
def calculate_score(self):
if self.output['compact']:
self.score = self.param['max_score']
else:
self.score = 0Want to see and learn more?
Want to start using and experience it yourself?