06 / Evidence before score
Turn an API security review into findings engineers can act on
Inspect exposed API behavior, headers, transport signals, and contract evidence, then organize the result around risk and remediation.
TRANSPORTobserved
AUTH BOUNDARYreview
HEADER POLICYfinding
CONTRACTattached
Evidence and inference stay separate.
Working reference
What goes in, what comes out, and what the result can prove.
Concrete artifact
A useful finding separates fact from inference
Observed: Strict-Transport-Security header absent
Inference: downgrade resistance may be weaker
Confidence: high
Next check: verify HTTPS redirect and edge configurationReview sequence
Three checks before the result becomes a decision.
Evidence
Include the exact observed signal and collection time.
Confidence
Distinguish confirmed behavior from inferred risk.
Remediation
Give an engineering action and a way to verify the fix.
Limits
What this workflow does not prove.
- This is a bounded posture review, not a penetration test.
- A clean result does not prove the absence of vulnerabilities.
- Authenticated and internal surfaces require separately authorized testing.
Questions worth answering
Before you put it into a real workflow.
Is this a penetration test?
No. It is a bounded posture review and does not replace an authorized manual penetration test.
What should I scan?
Only systems you own or have explicit permission to assess.
Does it store secrets?
Do not submit secrets unless a specific authenticated workflow requires them; use scoped credentials and follow the handling guidance shown in that workflow.
Next move
Start with one concrete API problem.
Keep the first step small. Move into a workspace when the result deserves to be saved, repeated, or shared.