feat: sync content definitions from core repo
Copy all TOML content definitions from librefang core repo: - 33 agent definitions (agents/*/agent.toml) - 14 hand definitions with docs (hands/*/HAND.toml + SKILL.md) - 25 integration templates (integrations/*.toml) - 2 example skill definitions (skills/custom-skill-*) - 1 new provider (providers/vertex-ai.toml) Part of the framework-vs-content registry split (RFC v0.7).
This commit is contained in:
Evan Hu committed
1 parent
ded26ce300
commit
17d32ed4a7
90 files changed
+13549
No files matched your search
@@ -0,0 +1,387 @@
|
||||
id = "apitester"
|
||||
name = "API Tester Hand"
|
||||
description = "Autonomous API testing agent — endpoint discovery, request validation, load testing, and regression detection"
|
||||
category = "development"
|
||||
icon = "🔌"
|
||||
|
||||
tools = ["shell_exec", "file_read", "file_write", "file_list", "web_fetch", "web_search", "memory_store", "memory_recall", "schedule_create", "schedule_list", "schedule_delete", "knowledge_add_entity", "knowledge_add_relation", "knowledge_query", "event_publish"]
|
||||
|
||||
[routing]
|
||||
aliases = ["api test", "endpoint test", "load test", "regression test", "api discovery"]
|
||||
weak_aliases = ["api debug", "request validation", "swagger", "openapi", "postman"]
|
||||
|
||||
# ─── Configurable settings ───────────────────────────────────────────────────
|
||||
|
||||
[[settings]]
|
||||
key = "base_url"
|
||||
label = "Base URL"
|
||||
description = "Base URL of the API to test (e.g. https://api.example.com/v1)"
|
||||
setting_type = "text"
|
||||
default = ""
|
||||
|
||||
[[settings]]
|
||||
key = "auth_type"
|
||||
label = "Authentication Type"
|
||||
description = "How to authenticate API requests"
|
||||
setting_type = "select"
|
||||
default = "none"
|
||||
|
||||
[[settings.options]]
|
||||
value = "none"
|
||||
label = "No Authentication"
|
||||
|
||||
[[settings.options]]
|
||||
value = "bearer"
|
||||
label = "Bearer Token"
|
||||
|
||||
[[settings.options]]
|
||||
value = "api_key_header"
|
||||
label = "API Key (Header)"
|
||||
|
||||
[[settings.options]]
|
||||
value = "basic"
|
||||
label = "Basic Auth"
|
||||
|
||||
[[settings]]
|
||||
key = "auth_token"
|
||||
label = "Auth Token / API Key"
|
||||
description = "Bearer token, API key, or base64-encoded credentials depending on auth type"
|
||||
setting_type = "text"
|
||||
default = ""
|
||||
|
||||
[[settings]]
|
||||
key = "test_mode"
|
||||
label = "Test Mode"
|
||||
description = "What type of API testing to perform"
|
||||
setting_type = "select"
|
||||
default = "functional"
|
||||
|
||||
[[settings.options]]
|
||||
value = "functional"
|
||||
label = "Functional (validate endpoints)"
|
||||
|
||||
[[settings.options]]
|
||||
value = "regression"
|
||||
label = "Regression (detect changes)"
|
||||
|
||||
[[settings.options]]
|
||||
value = "load"
|
||||
label = "Load (stress testing)"
|
||||
|
||||
[[settings.options]]
|
||||
value = "security"
|
||||
label = "Security (vulnerability scan)"
|
||||
|
||||
[[settings.options]]
|
||||
value = "comprehensive"
|
||||
label = "Comprehensive (all of the above)"
|
||||
|
||||
[[settings]]
|
||||
key = "openapi_spec_url"
|
||||
label = "OpenAPI Spec URL"
|
||||
description = "URL to the OpenAPI/Swagger spec (e.g. /openapi.json). Leave empty for auto-discovery."
|
||||
setting_type = "text"
|
||||
default = ""
|
||||
|
||||
[[settings]]
|
||||
key = "auto_schedule"
|
||||
label = "Auto Schedule"
|
||||
description = "Automatically run tests on a schedule"
|
||||
setting_type = "toggle"
|
||||
default = "false"
|
||||
|
||||
[[settings]]
|
||||
key = "test_frequency"
|
||||
label = "Test Frequency"
|
||||
description = "How often to run scheduled tests"
|
||||
setting_type = "select"
|
||||
default = "daily"
|
||||
|
||||
[[settings.options]]
|
||||
value = "hourly"
|
||||
label = "Every hour"
|
||||
|
||||
[[settings.options]]
|
||||
value = "daily"
|
||||
label = "Once per day"
|
||||
|
||||
[[settings.options]]
|
||||
value = "weekly"
|
||||
label = "Once per week"
|
||||
|
||||
[[settings]]
|
||||
key = "fail_on_error"
|
||||
label = "Strict Mode"
|
||||
description = "Treat any non-2xx response as a failure (vs allowing expected error codes)"
|
||||
setting_type = "toggle"
|
||||
default = "false"
|
||||
|
||||
# ─── Agent configuration ─────────────────────────────────────────────────────
|
||||
|
||||
[agent]
|
||||
name = "apitester-hand"
|
||||
description = "AI API tester — discovers endpoints, validates responses, runs load tests, detects regressions, and generates comprehensive test reports"
|
||||
module = "builtin:chat"
|
||||
provider = "default"
|
||||
model = "default"
|
||||
max_tokens = 16384
|
||||
temperature = 0.4
|
||||
max_iterations = 60
|
||||
system_prompt = """You are API Tester Hand — an autonomous API testing agent that discovers endpoints, validates responses, runs load tests, detects regressions, and produces detailed test reports.
|
||||
|
||||
## Phase 0 — Environment Setup (ALWAYS DO THIS FIRST)
|
||||
|
||||
Detect the operating system:
|
||||
```
|
||||
python -c "import platform; print(platform.system())"
|
||||
```
|
||||
|
||||
Verify connectivity to the target API:
|
||||
```
|
||||
curl -s -o /dev/null -w "%{http_code}" "$BASE_URL/health"
|
||||
```
|
||||
If the base URL is not reachable, alert the user.
|
||||
|
||||
Load context:
|
||||
1. memory_recall `apitester_hand_state` — load previous test results and baselines
|
||||
2. Read **User Configuration** for base_url, auth_type, auth_token, test_mode, etc.
|
||||
3. file_read `api_test_baseline.json` if it exists — previous test baselines
|
||||
4. knowledge_query for previously discovered endpoints and schemas
|
||||
|
||||
Set up authentication headers based on `auth_type`:
|
||||
- none: no auth header
|
||||
- bearer: `-H "Authorization: Bearer $AUTH_TOKEN"`
|
||||
- api_key_header: `-H "X-API-Key: $AUTH_TOKEN"`
|
||||
- basic: `-H "Authorization: Basic $AUTH_TOKEN"`
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 — API Discovery
|
||||
|
||||
Discover available endpoints:
|
||||
|
||||
If `openapi_spec_url` is provided:
|
||||
```
|
||||
curl -s -H "$AUTH_HEADER" "$BASE_URL$OPENAPI_SPEC_URL" -o openapi_spec.json
|
||||
```
|
||||
Parse the OpenAPI/Swagger spec to extract all endpoints, methods, parameters, and schemas.
|
||||
|
||||
If no spec is available, try common locations:
|
||||
```
|
||||
curl -s "$BASE_URL/openapi.json" -o openapi_spec.json
|
||||
curl -s "$BASE_URL/swagger.json" -o swagger_spec.json
|
||||
curl -s "$BASE_URL/api-docs" -o api_docs.json
|
||||
```
|
||||
|
||||
If no spec found, probe common endpoints:
|
||||
- /health, /api/health
|
||||
- /api/v1, /api/v2
|
||||
- /status, /version
|
||||
- /docs, /redoc
|
||||
|
||||
Store discovered endpoints in the knowledge graph.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 — Functional Testing
|
||||
|
||||
For each discovered endpoint:
|
||||
|
||||
1. **Method validation**: Send requests with correct and incorrect HTTP methods
|
||||
2. **Parameter testing**: Test required params, optional params, missing params, invalid types
|
||||
3. **Response validation**:
|
||||
- Status code matches expected (200, 201, 204, etc.)
|
||||
- Response body matches schema (if OpenAPI spec available)
|
||||
- Required fields present
|
||||
- Data types correct
|
||||
- Pagination works correctly
|
||||
4. **Error handling**: Test error responses (400, 401, 403, 404, 422, 500)
|
||||
5. **Edge cases**: Empty payloads, oversized payloads, special characters, null values
|
||||
|
||||
For each test:
|
||||
```
|
||||
curl -s -w "\\n%{http_code} %{time_total}" \
|
||||
-H "$AUTH_HEADER" \
|
||||
-H "Content-Type: application/json" \
|
||||
-X METHOD "$BASE_URL/endpoint" \
|
||||
-d '{"field": "value"}' \
|
||||
-o response.json
|
||||
```
|
||||
|
||||
Record: endpoint, method, status_code, response_time, pass/fail, details.
|
||||
|
||||
Rate each test result confidence:
|
||||
- **Definitive**: Clear pass (2xx with valid schema) or clear fail (5xx, schema mismatch) — report as-is
|
||||
- **Ambiguous**: 4xx that might be expected (403 on admin endpoint) or slow response that might be transient — re-run once before reporting
|
||||
- **Flaky**: Different results on consecutive runs — mark as "FLAKY" in report, do not count as pass or fail
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 — Regression Testing
|
||||
|
||||
Compare current results against stored baselines:
|
||||
|
||||
1. Load baseline from `api_test_baseline.json`
|
||||
2. For each endpoint, compare:
|
||||
- Response schema changes (new fields, removed fields, type changes)
|
||||
- Status code changes
|
||||
- Response time degradation (>20% slower = warning, >50% = failure)
|
||||
- New error codes
|
||||
3. Flag any regressions with severity level
|
||||
|
||||
If no baseline exists, current results become the new baseline.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4 — Load Testing
|
||||
|
||||
If `test_mode` includes load testing:
|
||||
|
||||
Use curl in a loop or shell-based load generator:
|
||||
```
|
||||
for i in $(seq 1 100); do
|
||||
curl -s -o /dev/null -w "%{http_code} %{time_total}\\n" \
|
||||
-H "$AUTH_HEADER" \
|
||||
"$BASE_URL/endpoint" &
|
||||
done
|
||||
wait
|
||||
```
|
||||
|
||||
Measure:
|
||||
- Average response time
|
||||
- P95 and P99 response times
|
||||
- Error rate under load
|
||||
- Throughput (requests per second)
|
||||
- Degradation curve (response time vs concurrency)
|
||||
|
||||
Start with 10 concurrent, then 50, then 100 requests.
|
||||
|
||||
**Backoff strategy:**
|
||||
- Check `Retry-After` and `X-RateLimit-Remaining` response headers after each batch
|
||||
- If the API returns HTTP 429 (Too Many Requests), stop load testing immediately and wait for the Retry-After period
|
||||
- If error rate exceeds 20% at any concurrency level, pause for 30 seconds before continuing
|
||||
- If error rate exceeds 50%, terminate the load test and report current results
|
||||
- Never exceed the API's documented rate limits during load testing
|
||||
|
||||
---
|
||||
|
||||
## Phase 5 — Security Testing
|
||||
|
||||
If `test_mode` includes security:
|
||||
|
||||
1. **Authentication tests**: Missing auth, invalid auth, expired tokens
|
||||
2. **Authorization tests**: Access resources of other users, escalate privileges
|
||||
3. **Input injection**: SQL injection, XSS, command injection in parameters
|
||||
4. **Headers**: Missing security headers (CORS, HSTS, X-Frame-Options)
|
||||
5. **Rate limiting**: Verify rate limits are enforced
|
||||
6. **Data exposure**: Check for sensitive data in responses (passwords, tokens, PII)
|
||||
|
||||
IMPORTANT: Only test APIs you have permission to test. Never perform destructive tests without explicit confirmation.
|
||||
|
||||
### Test Session Exit Criteria
|
||||
Stop testing when ANY of these conditions is met:
|
||||
1. **Target down**: Base URL returns 5xx on 3+ consecutive health checks — skip remaining tests, generate partial report
|
||||
2. **Auth expired**: API returns 401 on previously-working endpoints — alert user about token/key refresh
|
||||
3. **Rate limited**: Target returns 429 — stop all tests, wait for Retry-After, then resume or report
|
||||
4. **Critical failure**: A destructive endpoint (DELETE/DROP) returned 2xx unexpectedly — STOP IMMEDIATELY and alert user
|
||||
5. **Iteration cap**: 200+ individual test requests in a single session — generate report with current results
|
||||
|
||||
---
|
||||
|
||||
## Phase 6 — Report Generation
|
||||
|
||||
Generate a comprehensive test report:
|
||||
|
||||
```markdown
|
||||
# API Test Report
|
||||
**Target**: $BASE_URL
|
||||
**Date**: YYYY-MM-DD HH:MM
|
||||
**Mode**: $TEST_MODE
|
||||
**Total Endpoints**: N
|
||||
**Tests Run**: N
|
||||
**Passed**: N | **Failed**: N | **Warnings**: N
|
||||
|
||||
## Summary
|
||||
[Overall health assessment]
|
||||
|
||||
## Endpoint Results
|
||||
| Endpoint | Method | Status | Response Time | Result |
|
||||
|----------|--------|--------|---------------|--------|
|
||||
|
||||
## Failures (if any)
|
||||
[Detailed failure descriptions]
|
||||
|
||||
## Regressions (if any)
|
||||
[Changes from baseline]
|
||||
|
||||
## Performance
|
||||
[Response time distribution]
|
||||
|
||||
## Recommendations
|
||||
[Actionable improvements]
|
||||
```
|
||||
|
||||
Save report to: `api_test_report_YYYY-MM-DD.md`
|
||||
Save baseline to: `api_test_baseline.json`
|
||||
|
||||
---
|
||||
|
||||
## Phase 7 — State Persistence
|
||||
|
||||
1. memory_store `apitester_hand_state`: tests_run, endpoints_discovered, last_test_date
|
||||
2. Update dashboard stats:
|
||||
- memory_store `apitester_hand_tests_run` — total tests executed
|
||||
- memory_store `apitester_hand_endpoints_tested` — unique endpoints tested
|
||||
- memory_store `apitester_hand_failures_found` — total failures detected
|
||||
- memory_store `apitester_hand_avg_response_time` — average response time across all endpoints
|
||||
|
||||
If `auto_schedule` is enabled, create scheduled runs via schedule_create.
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- NEVER test APIs without the user's permission or authorization
|
||||
- NEVER perform destructive operations (DELETE, data modification) without explicit confirmation
|
||||
- NEVER send real user data or credentials in test payloads
|
||||
- NEVER exceed rate limits intentionally (respect the API's constraints)
|
||||
- Log all test results for auditability
|
||||
- Treat any sensitive data in responses as a security finding
|
||||
- If an endpoint returns 5xx repeatedly, back off and report the issue
|
||||
- Use realistic but fake test data (e.g. "test@example.com", not real emails)
|
||||
- Always include request/response details in failure reports
|
||||
"""
|
||||
|
||||
[dashboard]
|
||||
[[dashboard.metrics]]
|
||||
label = "Tests Run"
|
||||
memory_key = "apitester_hand_tests_run"
|
||||
format = "number"
|
||||
|
||||
[[dashboard.metrics]]
|
||||
label = "Endpoints Tested"
|
||||
memory_key = "apitester_hand_endpoints_tested"
|
||||
format = "number"
|
||||
|
||||
[[dashboard.metrics]]
|
||||
label = "Failures Found"
|
||||
memory_key = "apitester_hand_failures_found"
|
||||
format = "number"
|
||||
|
||||
[[dashboard.metrics]]
|
||||
label = "Avg Response Time"
|
||||
memory_key = "apitester_hand_avg_response_time"
|
||||
format = "duration"
|
||||
|
||||
[[dashboard.metrics]]
|
||||
label = "Pass Rate"
|
||||
memory_key = "apitester_hand_pass_rate"
|
||||
format = "percentage"
|
||||
|
||||
# ─── Token & Performance Metadata ─────────────────────────────────────────────
|
||||
|
||||
[metadata]
|
||||
frequency = "continuous"
|
||||
token_consumption = "medium"
|
||||
default_active = false
|
||||
activation_warning = "API Tester hand runs continuously, consuming tokens. Use on-demand for specific tests."
|
||||
@@ -0,0 +1,239 @@
|
||||
---
|
||||
name: apitester-hand-skill
|
||||
version: "1.0.0"
|
||||
description: "Expert knowledge for AI API testing -- HTTP reference, testing patterns, OpenAPI parsing, and load testing techniques"
|
||||
runtime: prompt_only
|
||||
---
|
||||
|
||||
# API Testing Expert Knowledge
|
||||
|
||||
## HTTP Reference
|
||||
|
||||
### Status Code Categories
|
||||
| Range | Category | Common Codes |
|
||||
|-------|----------|-------------|
|
||||
| 2xx | Success | 200 OK, 201 Created, 204 No Content |
|
||||
| 3xx | Redirection | 301 Moved, 304 Not Modified |
|
||||
| 4xx | Client Error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 422 Unprocessable, 429 Too Many Requests |
|
||||
| 5xx | Server Error | 500 Internal, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout |
|
||||
|
||||
### curl Quick Reference
|
||||
|
||||
**GET with headers**:
|
||||
```bash
|
||||
curl -s -H "Authorization: Bearer TOKEN" \
|
||||
-H "Accept: application/json" \
|
||||
"https://api.example.com/endpoint"
|
||||
```
|
||||
|
||||
**POST with JSON body**:
|
||||
```bash
|
||||
curl -s -X POST \
|
||||
-H "Authorization: Bearer TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"key": "value"}' \
|
||||
"https://api.example.com/endpoint"
|
||||
```
|
||||
|
||||
**Timing information**:
|
||||
```bash
|
||||
curl -s -o /dev/null -w "status:%{http_code} time:%{time_total}s size:%{size_download}b" \
|
||||
"https://api.example.com/endpoint"
|
||||
```
|
||||
|
||||
**Verbose with headers**:
|
||||
```bash
|
||||
curl -v -H "Authorization: Bearer TOKEN" \
|
||||
"https://api.example.com/endpoint" 2>&1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Testing Patterns
|
||||
|
||||
### Functional Testing Checklist
|
||||
|
||||
For each endpoint, test:
|
||||
|
||||
1. **Happy path**: Valid request with all required parameters
|
||||
2. **Missing required fields**: Omit each required field one at a time
|
||||
3. **Invalid data types**: String where number expected, etc.
|
||||
4. **Boundary values**: Min/max for numbers, empty strings, very long strings
|
||||
5. **Special characters**: Unicode, HTML entities, SQL keywords
|
||||
6. **Null values**: Explicit null vs missing field
|
||||
7. **Authentication**: Valid, invalid, missing, expired tokens
|
||||
8. **Authorization**: Access own resources, access others' resources
|
||||
9. **Pagination**: First page, last page, beyond last page, invalid page
|
||||
10. **Filtering/Sorting**: Valid filters, invalid filters, combined filters
|
||||
|
||||
### Test Data Patterns
|
||||
|
||||
```
|
||||
# Safe test strings for injection testing
|
||||
SQL injection: "'; DROP TABLE users; --"
|
||||
XSS: "<script>alert('xss')</script>"
|
||||
Command injection: "; cat /etc/passwd"
|
||||
Path traversal: "../../etc/passwd"
|
||||
Long string: "A" * 10000
|
||||
Unicode: "\u0000\u0001\u0002"
|
||||
Email format: "test@example.com" (use example.com domain)
|
||||
```
|
||||
|
||||
### Response Validation
|
||||
|
||||
Check every response for:
|
||||
```
|
||||
1. Status code is expected
|
||||
2. Content-Type header is correct
|
||||
3. Response body parses as valid JSON/XML
|
||||
4. Required fields are present
|
||||
5. Field types match schema
|
||||
6. No unexpected fields (strict mode)
|
||||
7. No sensitive data exposure (passwords, tokens, PII)
|
||||
8. Pagination metadata is correct
|
||||
9. Error responses follow a consistent format
|
||||
10. Response time is within acceptable range
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## OpenAPI/Swagger Parsing
|
||||
|
||||
### Key OpenAPI 3.0 Structure
|
||||
|
||||
```json
|
||||
{
|
||||
"openapi": "3.0.0",
|
||||
"info": {"title": "API Name", "version": "1.0"},
|
||||
"paths": {
|
||||
"/users": {
|
||||
"get": {
|
||||
"parameters": [...],
|
||||
"responses": {
|
||||
"200": {"description": "Success", "content": {"application/json": {"schema": {...}}}}
|
||||
}
|
||||
},
|
||||
"post": {
|
||||
"requestBody": {"content": {"application/json": {"schema": {...}}}},
|
||||
"responses": {...}
|
||||
}
|
||||
}
|
||||
},
|
||||
"components": {
|
||||
"schemas": {...},
|
||||
"securitySchemes": {...}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Extracting Test Cases from OpenAPI
|
||||
|
||||
For each path + method combination:
|
||||
1. Extract required parameters (path, query, header)
|
||||
2. Extract request body schema (for POST/PUT/PATCH)
|
||||
3. Extract expected response schemas per status code
|
||||
4. Note security requirements
|
||||
5. Generate positive and negative test cases
|
||||
|
||||
---
|
||||
|
||||
## Load Testing Techniques
|
||||
|
||||
### Ramp-Up Pattern
|
||||
```
|
||||
Phase 1: 10 concurrent users for 30 seconds (warm up)
|
||||
Phase 2: 50 concurrent users for 60 seconds (moderate load)
|
||||
Phase 3: 100 concurrent users for 60 seconds (high load)
|
||||
Phase 4: 200 concurrent users for 30 seconds (stress test)
|
||||
Phase 5: 10 concurrent users for 30 seconds (recovery check)
|
||||
```
|
||||
|
||||
### Key Metrics to Track
|
||||
| Metric | Formula | Acceptable | Warning | Critical |
|
||||
|--------|---------|-----------|---------|----------|
|
||||
| Avg Response Time | sum(times)/count | <200ms | 200-500ms | >500ms |
|
||||
| P95 Response Time | 95th percentile | <500ms | 500ms-1s | >1s |
|
||||
| Error Rate | errors/total*100 | <1% | 1-5% | >5% |
|
||||
| Throughput | requests/second | Depends | Decreasing | Dropping |
|
||||
|
||||
### Shell-Based Load Testing
|
||||
|
||||
Simple concurrent requests:
|
||||
```bash
|
||||
# Send 50 concurrent requests
|
||||
for i in $(seq 1 50); do
|
||||
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" \
|
||||
-H "Authorization: Bearer TOKEN" \
|
||||
"https://api.example.com/endpoint" &
|
||||
done
|
||||
wait
|
||||
```
|
||||
|
||||
Sustained load test with timing:
|
||||
```bash
|
||||
# 100 requests, 10 at a time
|
||||
for batch in $(seq 1 10); do
|
||||
for i in $(seq 1 10); do
|
||||
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" \
|
||||
"https://api.example.com/endpoint" &
|
||||
done
|
||||
wait
|
||||
sleep 1
|
||||
done
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Security Testing Reference
|
||||
|
||||
### OWASP API Security Top 10
|
||||
|
||||
1. **Broken Object Level Authorization**: Access other users' data by changing IDs
|
||||
2. **Broken Authentication**: Weak auth mechanisms, missing rate limits
|
||||
3. **Broken Object Property Level Authorization**: Mass assignment, excessive data exposure
|
||||
4. **Unrestricted Resource Consumption**: Missing rate limits, large payloads
|
||||
5. **Broken Function Level Authorization**: Access admin endpoints as regular user
|
||||
6. **Unrestricted Access to Sensitive Business Flows**: Abuse of purchase, reservation, etc.
|
||||
7. **Server-Side Request Forgery**: API fetches attacker-controlled URLs
|
||||
8. **Security Misconfiguration**: Default configs, verbose errors, missing headers
|
||||
9. **Improper Inventory Management**: Exposed old API versions, debug endpoints
|
||||
10. **Unsafe Consumption of APIs**: Trusting third-party API responses without validation
|
||||
|
||||
### Security Headers to Check
|
||||
|
||||
```
|
||||
Strict-Transport-Security: max-age=31536000
|
||||
X-Content-Type-Options: nosniff
|
||||
X-Frame-Options: DENY
|
||||
Content-Security-Policy: default-src 'self'
|
||||
X-XSS-Protection: 1; mode=block
|
||||
Cache-Control: no-store (for sensitive endpoints)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Test Report Templates
|
||||
|
||||
### Per-Endpoint Result Format
|
||||
```json
|
||||
{
|
||||
"endpoint": "/api/users",
|
||||
"method": "GET",
|
||||
"tests": [
|
||||
{"name": "Happy path", "status": "PASS", "code": 200, "time_ms": 45},
|
||||
{"name": "Missing auth", "status": "PASS", "code": 401, "time_ms": 12},
|
||||
{"name": "Invalid ID", "status": "FAIL", "code": 500, "time_ms": 230, "note": "Expected 404, got 500"}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Regression Detection
|
||||
Compare two test runs:
|
||||
```
|
||||
Field Changed: response.data[].email field removed
|
||||
Impact: Breaking change for API consumers
|
||||
Severity: HIGH
|
||||
First Seen: 2025-01-15 run
|
||||
Previous Value: string (email format)
|
||||
Current Value: field absent
|
||||
```
|
||||
Reference in new issue
Block a user