Thema: regression-testing
-
Prüfen, dass Profilaktualisierungen keine privilegierten Kontofelder zuweisen können
Erstellt eine eng gefasste Regression für Aktualisierungen, die gewöhnliche Profildaten zusammen mit Feldern entgegennehmen, die die aufrufende Partei nicht kontrollieren darf. Die Methode schlägt eine explizite Feldzuständigkeit statt einer allgemeinen Checkliste zur Eingabevalidierung vor.
-
Konfigurationsänderungen testen, die die Befugnis einer anderen Person verändern
Konfigurationsschreibvorgänge identifizieren, die indirekt Berechtigungen gewähren, selbst wenn ihr Endpunkt wie eine gewöhnliche Einstellungsbearbeitung aussieht. Dieser Vorschlag folgt der resultierenden Befugnisänderung, statt das Risiko am Routennamen zu beurteilen.
-
Autorisierung anhand von Ressourcenbeziehungen statt Rollennamen testen
Prüfen, ob eine aufrufende Partei über die vom Produkt tatsächlich zugesicherte Beziehung auf ein bestimmtes Objekt einwirken kann. Diese vorgeschlagene Labormethode behandelt Rollenbezeichnungen als Attribute der Testfixtur, nicht als Testorakel.
-
Das Autorisierungsorakel für gemischte Batch-Anfragen definieren
Mehrdeutige Zugriffsregeln bei Batch-Operationen aufdecken, bevor ein Agent Tests schreibt, die jede beliebige Antwort abnicken, die die Implementierung zufällig zurückgibt. Der Vorschlag konzentriert sich auf gemischten Besitz innerhalb einer Anfrage.
-
Benachbarte Zugriffspfade nach einer eng begrenzten Sicherheitskorrektur prüfen
Eine Regression gerade so weit ausweiten, dass geprüft wird, ob eine reparierte Richtliniengrenze auch für benachbarte Pfade gilt. Diese ursprüngliche Methode vermeidet, ein ganzes Feature allein deshalb als behoben zu erklären, weil eine gemeldete Anfrage nun abgelehnt wird.
Maschinenlesbar: JSON