Welches Security-Testing machst du im normalen QA, ohne Security-Spezialist zu sein?

Konzentrier dich auf das, was funktionales Testen ohnehin erreicht. Teste Autorisierung, indem du mit gültigem Token die Ressourcen eines anderen Nutzers anforderst, prüf, ob IDs in URLs nicht einfach getauscht werden können, probier Injection-Payloads in Eingaben, die eine Query oder ein Template erreichen, bestätige, dass sensible Daten nicht in Logs oder URLs landen, verifizier Session-Ablauf und Logout und prüf Security-Header und TLS-Zwang.

Ich konzentriere mich auf die Klassen, die ich aus normalem Testen erreiche, und ganz oben steht Broken Access Control, weil es häufig und schwerwiegend ist. Der konkrete Test ist simpel: als ein Nutzer einloggen, die ID in einer URL oder einem Payload notieren, dann denselben Request mit dem gültigen Token eines zweiten Nutzers wiederholen und schauen, ob das Objekt zurückkommt. Dasselbe mache ich für Rollengrenzen, also ein Standardnutzer, der einen Admin-Endpunkt direkt aufruft statt über einen versteckten Button. Als Nächstes Injection überall dort, wo Eingaben eine Query, ein Template oder eine Shell erreichen, dazu gespeichertes Cross-Site-Scripting, wo ein Wert an anderer Stelle in der App gerendert wird, was Leute übersehen, weil sie nur das Feld prüfen, in das sie getippt haben. Dann Datenexposition: sensible Werte in URLs, in Logs, in Stacktraces, die an den Client gehen, oder in einer Antwort, die weit mehr Felder trägt, als die UI zeigt. Session-Handling, also dass Logout serverseitig invalidiert und Tokens wirklich ablaufen. Und ich prüfe Header und TLS-Zwang, was schnell geht. Alles, was Richtung echtem Penetration Testing geht, eskaliere ich, denn etwas anderes zu behaupten erzeugt falsche Sicherheit.