Benutzer können `?account_id=123` in `124` ändern und die Daten anderer Benutzer sehen. Welche Kategorie ist das und wie behebst du es?

Wenn das Ändern von account_id=123 in 124 die Daten einer anderen Person zurückgibt, identifiziert die Anwendung das Objekt, fragt aber nie, ob dieser Benutzer es sehen darf. Das ist eine unsichere direkte Objektreferenz (IDOR), eine Form der fehlerhaften Zugriffskontrolle — OWASPs Risikokategorie Nummer eins.

Die korrekte Behebung: serverseitige Autorisierung auf Objektebene

Bei jeder Anfrage, die ein konkretes Objekt betrifft, muss der Server prüfen, dass der authentifizierte Principal für genau dieses Objekt autorisiert ist — etwa dass das Konto dem aktuellen Benutzer gehört (oder mit ihm geteilt ist) — und andernfalls ablehnen. Diese Prüfung muss serverseitig liegen und auf allen Zugriffspfaden laufen, nicht nur in der Oberfläche, die „normalerweise" das richtige Konto zeigt. Die Referenz selbst kann ein einfacher Integer bleiben; entscheidend ist die Autorisierungsentscheidung dahinter.

Warum die Distraktoren falsch sind

• Die Zahl bereinigen validiert das Format, nicht die Eigentümerschaft. 124 ist ein vollkommen gültiger Integer und gehört trotzdem jemand anderem.
• Die account_id verschlüsseln oder verschleiern ist Sicherheit durch Obskurität. Verschlüsselte oder zufällige IDs leaken in URLs, Logs, Referer-Headern und im Browserverlauf und lassen sich wiederholen; der Wechsel zu UUIDs erhöht die Ratehürde, gibt aber weiterhin Daten an jeden zurück, der eine gültige Referenz erlangt. Der eigentliche Mangel ist die fehlende Autorisierungsprüfung.
• Von GET auf POST wechseln ändert das HTTP-Verb und wo der Parameter reist, nicht aber, ob der Server die Anfrage autorisiert. Der Angreifer schickt einfach ein POST.

Worauf der Interviewer achtet

Er will, dass du die Schwachstellenklasse korrekt benennst (fehlerhafte Zugriffskontrolle / IDOR), den verlockenden, aber oberflächlichen Behebungen widerstehst und die Kontrolle an der richtigen Stelle platzierst: eine serverseitige, objektbezogene Autorisierungsentscheidung, einheitlich angewendet. Starke Kandidaten ergänzen, dass dies am besten zentral durchgesetzt wird — über eine gemeinsame Autorisierungsschicht oder Middleware — damit kein Endpunkt die Prüfung vergisst, und dass Verschleierung höchstens Defense-in-Depth ist, nie die Behebung.