Den Befund an die richtige Antwort binden
Eine URL kann ohne Anmeldung eine HTML-Seite und mit passendem Token JSON liefern. Ein Proxy kann eine eigene Fehlerseite zurückgeben, bevor die Anfrage die Anwendung erreicht. Ein Redirect kann zu einem anderen Host führen. Deshalb reichen „Header vorhanden“ und der Domainname allein für die Einordnung nicht.
Halten Sie bei einem eigenen, bereits vorliegenden Befund diese Angaben zusammen fest:
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Angabe | Warum sie zur Aussage gehört |
|---|---|
| Angefragte URL und tatsächliches Antwortziel | Ein vorgeschalteter Dienst oder Redirect kann einen anderen Teil der Architektur sichtbar machen. |
| Methode, Status und Zeitpunkt | GET, OPTIONS und Fehlerantworten müssen nicht dieselben Header tragen; Konfigurationen ändern sich. |
| Erwarteter und tatsächlicher Inhaltstyp | Eine Anmeldeseite ist keine repräsentative JSON-Antwort des geschützten Endpunkts. |
| Anmeldung und Browserkontext | Eine öffentliche Probe sagt nichts über Antworten mit Cookies oder Tokens. Bei CORS gehören Origin und Credentials-Modus dazu. |
| Unvollständige oder nicht lesbare Antwort | Ein Timeout, abgeschnittener Inhalt oder nicht ausgewerteter Body begrenzt den Befund. |
Geben Sie keine vollständigen Tokens, Cookies oder Kundendaten weiter. Für die gemeinsame Fehlersuche genügt häufig ein bereinigter Ausschnitt mit den betroffenen Headern und einer internen, zugriffsgeschützten Referenz auf das Original.
Content-Type: die tatsächliche Darstellung benennen
Content-Type beschreibt den Medientyp der Darstellung. Für eine JSON-Antwort ist typischerweise application/json passend, für ein Problem-Details-Dokument application/problem+json. Eine API darf aber ebenso eine PDF-Datei, ein Bild, XML oder Text ausliefern. „Nicht JSON“ bedeutet daher nicht automatisch „unsicher“. Entscheidend ist, ob der Vertrag, der deklarierte Typ und die tatsächlich gelieferten Bytes zusammenpassen. Die Grundlage ist RFC 9110, Abschnitt 8.3.
Wenn ein Client statt des erwarteten JSON ein HTML-Dokument erhält, ändern Sie nicht blind den Header in application/json. Untersuchen Sie zunächst, ob die Antwort von einer Loginweiterleitung, einer Fehlerseite am Gateway oder einem falschen Pfad stammt. Ein falscher Header repariert den Inhalt nicht. Ebenso beweist ein syntaktisch korrekter Typ weder ein gültiges JSON-Dokument noch erlaubte Felder oder richtige Daten.
Für Antworten ohne Inhalt gelten besondere Regeln. Beispielsweise enthält eine 204 No Content-Antwort keinen Antwortinhalt; für ihre Bewertung ist eine pauschale „JSON-Header fehlt“-Regel unpassend. Auch bei HEAD und 304 Not Modified müssen Sie die HTTP-Semantik berücksichtigen. Erzeugen Sie keine künstlichen Bodys, um einen Headercheck zufriedenzustellen.
X-Content-Type-Options: nosniff ergänzt den korrekten Typ im Browserkontext. Unter anderem blockiert der Browser damit Script- oder Stylesheetverwendungen mit unpassendem MIME-Typ; weitere Wirkung hängt vom Verwendungskontext ab. Der Header validiert keine JSON-Struktur und verhindert keine unberechtigte Datenfreigabe. Die Web-Grundlage zu nosniff und die MDN-Referenz erklären diese Browsermechanik.
Nachweis und Rücknahme: Prüfen Sie nach einer Änderung in einer eigenen Testumgebung je eine erfolgreiche Antwort, einen fachlichen Fehler, eine abgewiesene Anmeldung und einen gegebenenfalls vorgesehenen Download. Vergleichen Sie erwarteten Inhalt und Typ. Wenn eine zentrale Headerregel mehrere Antwortarten falsch etikettiert, nehmen Sie diese Regel zurück und setzen Sie die Typen bei der jeweils erzeugenden Antwort.
Cache-Control: öffentliche Daten und persönliche Antworten unterscheiden
Caching kann eine bewusst öffentliche API entlasten. Ein öffentliches Verzeichnis mit identischem Inhalt für alle Nutzer kann anders behandelt werden als die persönliche Exportliste eines Teams. Vor einer Cache-Entscheidung müssen Sie deshalb die Daten und den Cache kennen: Ein privater Browsercache gehört zu einem Client; ein gemeinsamer Cache wie ein CDN bedient mehrere Clients.
Für sensible persönliche Antworten ist Cache-Control: no-store eine sinnvolle Ausgangsregel, wenn keine Speicherung in HTTP-Caches gewünscht ist. Das ist eine Anweisung an Caches, keine Zugriffskontrolle und keine rückwirkende Löschung zuvor gespeicherter Kopien. private verhindert im unqualifizierten Fall die Speicherung durch gemeinsame Caches, lässt aber private Speicherung unter den übrigen Regeln zu. no-cache bedeutet grundsätzlich erneute Validierung vor Wiederverwendung, nicht „nichts speichern“. Die allgemeinen Regeln erklärt Cache-Control; normativ maßgeblich ist RFC 9111.
Die folgenden Ausschnitte sind synthetische Vertragsbeispiele, keine gemessenen Serverantworten:
# Persönliche Exportliste: keine Speicherung in HTTP-Caches vorgesehen
Content-Type: application/json
Cache-Control: no-store
# Bewusst öffentliches, für alle identisches Verzeichnis
Content-Type: application/json
Cache-Control: public, max-age=60
Die zweite Regel ist nur passend, wenn Inhalt, Berechtigungsmodell und Cache-Schlüssel tatsächlich zu dieser öffentlichen Nutzung passen. Die beispielhaften 60 Sekunden sind keine allgemeine Empfehlung. Eine Antwort mit individuellen Feldern wird durch den Header public nicht zu zulässig öffentlichen Daten.
Ein häufiger Irrtum betrifft Cookies: Set-Cookie allein verhindert nach HTTP-Cacheregeln keine Speicherung. Ein Cache kann solche Antworten in seiner eigenen Konfiguration strenger behandeln; auf diese Annahme sollten Sie sich ohne Prüfung nicht verlassen. Auch eine Anfrage mit Authorization ist kein universelles Cacheverbot, denn bestimmte Antwortdirektiven können gemeinsame Wiederverwendung erlauben. RFC 9111, Abschnitte 3.5 und 7.3.
Konkreter Prüfschritt: Verwenden Sie in Ihrer isolierten Umgebung zwei eigene Testkonten mit deutlich unterscheidbaren, harmlosen Daten. Betrachten Sie Antworten am Anwendungsserver und über den echten Test-Proxy. Es darf keine Antwort, kein Cookie und kein personenbezogenes Feld des ersten Kontos beim zweiten erscheinen. Prüfen Sie zusätzlich Cache-Schlüssel, Bypassregeln und Fehlerantworten. Ein Cache-Hit-Header allein ist kein vollständiger Beleg, ein fehlender Hit-Header kein Beweis für fehlendes Caching.
Tritt eine Vermischung auf, stoppen Sie die betroffene gemeinsame Speicherung, sichern Sie den notwendigen bereinigten Befund und klären Sie die bereits vorhandenen Einträge anhand der eigenen Cacheverwaltung. Zurück auf eine riskante Cache-Regel zu schalten, um Performance wiederherzustellen, ist keine sichere Rücknahme. Erst eine nachvollziehbar getrennte oder bewusst öffentliche Darstellung erlaubt das erneute Aktivieren.
Allow und OPTIONS: Ankündigung ist keine Berechtigung
Allow nennt die vom Ziel angekündigten HTTP-Methoden. Bei einer 405 Method Not Allowed-Antwort ist dieses Feld vorgeschrieben. Eine OPTIONS-Antwort muss dagegen nicht jedes Mal ein vollständiges Methodenverzeichnis liefern. Access-Control-Allow-Methods gehört zu CORS und ist wiederum eine andere Aussage. RFC 9110, Abschnitte 9.3.7 und 10.2.1.
Steht DELETE in Allow, ist damit weder ein Löschaufruf ausgeführt noch der Zugriff eines unberechtigten Nutzers nachgewiesen. Eine Anwendung kann diese Methode benötigen und sie korrekt absichern. Umgekehrt beweist das Weglassen aus einer Liste nicht, dass der Server einen solchen Aufruf ablehnt. Prüfen Sie die tatsächliche Routen-/Methodenzuordnung und Funktionsberechtigungen mit eigenen Testdaten, bevor Sie Methoden pauschal entfernen.
Auch TRACE in einer Liste ist zunächst ein Ankündigungssignal. Der Fetch Standard verbietet TRACE, TRACK und CONNECT als Methoden für entsprechende Browseraufrufe. Daraus folgt nicht automatisch das oft wiederholte Szenario, JavaScript könne per TRACE Sitzungscookies auslesen. Ein unnötig angebotener Diagnoseweg bleibt ein Härtungsthema; die Behauptung eines konkreten Datenabflusses braucht andere Belege. Fetch: Methods.
Die HTTP-Eigenschaft safe bedeutet bei GET oder OPTIONS, dass der Client nach der definierten Semantik keine Zustandsänderung anfordert. Sie garantiert keine nebenwirkungsfreie fehlerhafte Serverimplementierung. Verwenden Sie daher auch vermeintlich harmlose Prüfungen nur im passenden eigenen oder ausdrücklich freigegebenen Umfeld. Nach einer Methodenänderung müssen vorgesehene Clients einschließlich Preflights weiter funktionieren; korrigieren Sie bei Problemen die konkrete Routenregel statt alle Methoden freizuschalten.
Serverheader und CVE-Hinweise: Paketstand statt Banner bewerten
Server und X-Powered-By können Hinweise auf eine beteiligte Technologie enthalten. Sie können fehlen, verändert sein oder den Proxy statt der Anwendung beschreiben. Ein Banner ist deshalb kein verlässliches Softwareinventar. HTTP empfiehlt, unnötig genaue Produktinformationen zu begrenzen; das Entfernen eines Banners schließt aber keine Sicherheitslücke. RFC 9110, Abschnitt 10.2.4.
Eine CVE ist eine Kennung für ein veröffentlichtes Sicherheitsproblem. Ein Treffer anhand einer Versionszeichenfolge ist ein Anlass zum Abgleich: Welches Paket ist tatsächlich installiert, welcher Hersteller pflegt es, welche Konfiguration ist betroffen und ist die Korrektur bereits enthalten? Manche Hersteller übernehmen Sicherheitskorrekturen in ältere Versionslinien. Ein solcher Backport erklärt, warum eine alte sichtbare Versionsnummer allein kein Verwundbarkeitsbeweis ist. Red Hat: Backporting Security Fixes.
Der API Security Check verwendet eine begrenzte lokale CVE-Auswahl für bestimmte erkennbare Produktversionen. Er führt keinen vollständigen aktuellen Schwachstellenabgleich und keinen Exploitnachweis durch. Ohne verwertbare Version oder passende Abdeckung bleibt diese Frage offen. Ein fehlender Treffer rechtfertigt daher weder „alles aktuell“ noch „keine bekannten Lücken“.
Nutzen Sie das API-Inventar für die tatsächlichen Versionen und Zuständigkeiten. Gezielte Updates gehören zum Betrieb: relevante Herstellerhinweise prüfen, Änderung in geeigneter Umgebung erproben und einen Rückweg vorbereiten, der nicht unbemerkt den bereits bekannten Fehler wieder einführt.
Messlücken und Noten richtig lesen
Eine ausgefallene oder nicht auswertbare Probe ist kein positiver Befund. Eine teilweise Messung kann zugleich einen konkreten Treffer und offene Fragen enthalten. Beispielsweise kann ein sichtbarer Stacktrace relevant bleiben, obwohl der restliche Antworttext abgeschnitten wurde. Umgekehrt sagt ein nicht durchsuchbarer Inhalt nichts über das Fehlen interner Details.
Lesen Sie eine Bewertung in dieser Reihenfolge: Ziel und Kontext, Messzeit und Umfang, konkrete Befunde, Messlücken, anschließend die zusammenfassende Note. Die Note beschreibt das begrenzte Bewertungsmodell. Sie beantwortet weder die Objektberechtigungsfrage noch die sichere Verarbeitung Ihrer Geschäftsabläufe. Für eine Anwendungsfreigabe brauchen Sie dazu passende eigene Prüfungen.
Der API Security Check kann festgelegte öffentliche Antwortmerkmale beobachten. Er sendet GET und OPTIONS sowie eine begrenzte GET-Fehlerprobe; er untersucht keine angemeldeten Rollen. Methoden werden aus Angaben gelesen, Rate-Limits nicht unter Last nachgewiesen und Antworten nicht als umfassend sichere Anwendung zertifiziert. Ein Report hält diesen Messstand fest, erweitert ihn aber nicht.
Den Befund in eine überprüfbare Änderung übersetzen
Formulieren Sie eine konkrete Erwartung: „Die persönliche Exportliste wird von unserem gemeinsamen Cache nicht gespeichert“ ist prüfbarer als „alle Header grün“. Benennen Sie die verantwortliche Schicht und sichern Sie die bisherige Konfiguration. Ändern Sie eine zusammenhängende Regel, prüfen Sie den erlaubten Normalfall und den relevanten Gegenfall und halten Sie den tatsächlichen Effekt fest.
Wenn die Beobachtung nicht zum erwarteten Pfad passt, klären Sie zunächst Routing, Anmeldung und Proxyantwort. Wenn Rechte oder Geschäftslogik betroffen sind, gehen Sie in Anwendungstests und Codeprüfung. Der passende nächste Schritt folgt der offenen Frage, nicht der Anzahl auffälliger Header.
Quellenstand
Geprüft am 27. September 2026: RFC 9110, RFC 9111, Fetch Standard, MDN zu nosniff und die Herstellererklärung zu Backports. Die Beispiele illustrieren Entscheidungen; eine Konfiguration Ihrer API wurde damit nicht praktisch abgenommen.