Web und API: Angemeldet heißt nicht berechtigt
Objekt-, Funktions- und Feldrechte direkt am Server prüfen.
Der Prüfauftrag
Prüfliste für Entwickler und autorisierte Tester. Ausschließlich eigene beziehungsweise ausdrücklich freigegebene Testsysteme und getrennte Testkonten verwenden.
Am Ende hast du:Eine dokumentierte Erstprüfung mit nachvollziehbaren Nachweisen und einer Liste offener Maßnahmen.
Beweisen statt vermuten.
Mit zwei freigegebenen Testkonten Zugriffe auf eigene und fremde Testobjekte vergleichen; die negative Gegenprobe muss serverseitig scheitern.
Status, Prüfbereich und Notizen bleiben in diesem Browser. Keine Übertragung an MauriSec. Ohne Speicherung geht der Stand beim Verlassen verloren; gespeicherte Daten bleiben bis zu deiner Löschung. Keine Geheimnisse, Zugangsdaten oder fremden personenbezogenen Daten eintragen.
Rollen, Mandanten, Aktionen und geschützte Objekte in einer Berechtigungsmatrix erfassen; Standardentscheidung bei fehlender Freigabe ablehnen.
So belegst du es: Versionierte Matrix mit nachvollziehbaren Erlaubnis- und Verbotsfällen.
Nachweis und nächsten Schritt notieren
Jeden serverseitigen Zugriff auf das konkrete Objekt und die Aktion autorisieren; übermittelte Objekt-IDs nicht als Berechtigungsnachweis behandeln.
So belegst du es: Negative Direktaufrufe zwischen zwei Konten desselben und unterschiedlicher Mandanten.
Nachweis und nächsten Schritt notieren
Administrative Funktionen separat prüfen; versteckte Menüs oder clientseitige Rollenanzeigen sind keine Zugriffssperre.
So belegst du es: API-Tests mit nicht privilegiertem Konto für administrative Endpunkte und Methoden.
Nachweis und nächsten Schritt notieren
Erlaubte Eingabe- und Ausgabefelder ausdrücklich festlegen; sensible Eigenschaften weder beliebig überschreiben noch unberechtigt ausliefern lassen.
So belegst du es: Tests zusätzlicher Felder und geprüfte Antworten für unterschiedliche Rollen.
Nachweis und nächsten Schritt notieren
Falls JWTs genutzt werden: erlaubte Algorithmen und vertrauenswürdige Schlüssel festlegen; erwarteten Aussteller, Empfänger und zeitliche Gültigkeit prüfen.
So belegst du es: Ablehnung manipulierten, abgelaufenen sowie für andere Empfänger ausgestellten Tokens.
Nachweis und nächsten Schritt notieren
Berechtigungen auch bei Downloads, Suchergebnissen, Exporten und verschachtelten Ressourcen durchsetzen.
So belegst du es: Abgedeckte alternative Zugriffspfade statt ausschließlich getesteter Detailseite.
Nachweis und nächsten Schritt notieren
Bei automatisch mitgesendeten Browser-Zugangsdaten zustandsändernde Aktionen angemessen gegen CSRF schützen; CORS nicht als Autorisierung verwenden.
So belegst du es: Gezielte Herkunfts-/CSRF-Tests und dokumentierte CORS-Konfiguration.
Nachweis und nächsten Schritt notieren
Grenzfälle, entzogene Rechte und technische Fehler prüfen; bei fehlgeschlagener Prüfung sicher abbrechen und sensible Details nicht offenlegen.
So belegst du es: Regressionstests für Rollenwechsel, fehlende Zuordnung und Fehlerpfade.
Nachweis und nächsten Schritt notieren
Fehlgeschlagene und besonders relevante Zugriffe nachvollziehbar protokollieren, ohne Geheimnisse zu speichern; Aufwand und Datenmengen begrenzen.
So belegst du es: Auffindbare Testereignisse, Datenminimierung und getestete Ressourcenlimits.
Nachweis und nächsten Schritt notieren
Deine nächste Arbeit.
Beginne mit den vorrangigen Punkten. Markierte Lücken erscheinen hier mit deinen nächsten Schritten.
Grenzen und Primärquellen
Unvorhersehbare IDs helfen gegen Erraten, ersetzen aber keine Autorisierung. Authentifizierung, Objektzugriff, Funktionsrechte und Feldfreigaben sind getrennte Prüfungen. Token- und Session-Verhalten hängt vom gewählten Profil ab; nicht jede Anwendung benötigt JWTs. Erfolgreiche Einzeltests beweisen keine vollständige Sicherheit aller API-Pfade.
OWASP: Authorization Cheat Sheet ↗OWASP API Security: Broken Object Level Authorization ↗OWASP: REST Security Cheat Sheet ↗OWASP: API Security Top 10 ↗Prüfbericht / Selbsteinschätzung
Web und API: Angemeldet heißt nicht berechtigt · v2026.11 · 10.11.2026 ·
0/9 bearbeitet · 0 Lücken. Keine unabhängige Prüfung oder Zertifizierung.
1. Rollen, Mandanten, Aktionen und geschützte Objekte in einer Berechtigungsmatrix erfassen; Standardentscheidung bei fehlender Freigabe ablehnen.
Status: Offen
Erwarteter Nachweis: Versionierte Matrix mit nachvollziehbaren Erlaubnis- und Verbotsfällen.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
2. Jeden serverseitigen Zugriff auf das konkrete Objekt und die Aktion autorisieren; übermittelte Objekt-IDs nicht als Berechtigungsnachweis behandeln.
Status: Offen
Erwarteter Nachweis: Negative Direktaufrufe zwischen zwei Konten desselben und unterschiedlicher Mandanten.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
3. Administrative Funktionen separat prüfen; versteckte Menüs oder clientseitige Rollenanzeigen sind keine Zugriffssperre.
Status: Offen
Erwarteter Nachweis: API-Tests mit nicht privilegiertem Konto für administrative Endpunkte und Methoden.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
4. Erlaubte Eingabe- und Ausgabefelder ausdrücklich festlegen; sensible Eigenschaften weder beliebig überschreiben noch unberechtigt ausliefern lassen.
Status: Offen
Erwarteter Nachweis: Tests zusätzlicher Felder und geprüfte Antworten für unterschiedliche Rollen.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
5. Falls JWTs genutzt werden: erlaubte Algorithmen und vertrauenswürdige Schlüssel festlegen; erwarteten Aussteller, Empfänger und zeitliche Gültigkeit prüfen.
Status: Offen
Erwarteter Nachweis: Ablehnung manipulierten, abgelaufenen sowie für andere Empfänger ausgestellten Tokens.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
6. Berechtigungen auch bei Downloads, Suchergebnissen, Exporten und verschachtelten Ressourcen durchsetzen.
Status: Offen
Erwarteter Nachweis: Abgedeckte alternative Zugriffspfade statt ausschließlich getesteter Detailseite.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
7. Bei automatisch mitgesendeten Browser-Zugangsdaten zustandsändernde Aktionen angemessen gegen CSRF schützen; CORS nicht als Autorisierung verwenden.
Status: Offen
Erwarteter Nachweis: Gezielte Herkunfts-/CSRF-Tests und dokumentierte CORS-Konfiguration.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
8. Grenzfälle, entzogene Rechte und technische Fehler prüfen; bei fehlgeschlagener Prüfung sicher abbrechen und sensible Details nicht offenlegen.
Status: Offen
Erwarteter Nachweis: Regressionstests für Rollenwechsel, fehlende Zuordnung und Fehlerpfade.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
9. Fehlgeschlagene und besonders relevante Zugriffe nachvollziehbar protokollieren, ohne Geheimnisse zu speichern; Aufwand und Datenmengen begrenzen.
Status: Offen
Erwarteter Nachweis: Auffindbare Testereignisse, Datenminimierung und getestete Ressourcenlimits.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
Unvorhersehbare IDs helfen gegen Erraten, ersetzen aber keine Autorisierung. Authentifizierung, Objektzugriff, Funktionsrechte und Feldfreigaben sind getrennte Prüfungen. Token- und Session-Verhalten hängt vom gewählten Profil ab; nicht jede Anwendung benötigt JWTs. Erfolgreiche Einzeltests beweisen keine vollständige Sicherheit aller API-Pfade.