Ein Cookie mit dem Namen .AspNetCore.Cookies beendet die Diskussion, bevor sie angefangen hat. Wer dieses Cookie im Entwicklertools-Fenster einer Website sieht, weiß mit Sicherheit: Hier läuft ASP.NET Core. Keine Vermutung, kein Bauchgefühl, sondern ein Beweis, der sich in Sekunden prüfen lässt, ohne einen einzigen Scan zu starten. Die meisten Fragen zum eingesetzten Tech-Stack sind allerdings nicht so eindeutig zu beantworten, und genau darum geht es hier: um die vielen kleinen Spuren, die ein Microsoft-Stack im Alltag hinterlässt, und um die Frage, wie belastbar jede einzelne davon eigentlich ist.
Warum das überhaupt jemanden interessiert
Für IT-Verantwortliche ist die Antwort naheliegend: Was von außen über die eigene Infrastruktur erkennbar ist, sollten sie kennen, bevor es jemand anderes für sie herausfindet. Wer weiß, dass sein Server-Header offenherzig Kestrel verrät, kann eine bewusste Entscheidung treffen, ob das so bleiben soll. Für Auditoren und technisch Interessierte ist die Fragestellung aus einem anderen Grund relevant: Stack-Erkennung ist die Grundlage jeder seriösen technischen Bestandsaufnahme, und die Qualität dieser Erkennung hängt komplett davon ab, wie gut man zwischen sicherem Beweis und bloßer Vermutung unterscheidet.
Klartext für Geschäftsführer: Ihre Website verrät im Hintergrund technische Details, die für Sie unsichtbar sind, aber für jeden, der sie ansieht, öffentlich einsehbar. Das ist erst einmal kein Sicherheitsproblem, viele dieser Signale lassen sich mit vertretbarem Aufwand reduzieren, ohne dass ein Techniker die Seite umbauen muss. Ein Signal aus diesem Artikel ist allerdings kein bloßes Detail, sondern ein handfestes Risiko: eine öffentlich sichtbare Fehlerseite mit Stacktrace, dazu gleich mehr.
Die direkten Spuren: Header, Cookies, Pfade
Ein Response-Header ist der ehrlichste Ort, um nach einem Microsoft-Stack zu suchen, weil der Server hier oft ungefragt Auskunft gibt. Server: Kestrel oder Microsoft-IIS/10.0 steht in vielen Fällen einfach so im Klartext in der Antwort, X-Powered-By: ASP.NET ebenso. Etwas versteckter, aber genauso aussagekräftig sind X-AspNet-Version und X-AspNetMvc-Version, die konkrete Framework-Versionen preisgeben, sowie x-ms-request-id und x-azure-ref, zwei Header, die praktisch nur bei Azure-gehosteten Diensten auftauchen. Der Header Request-Context: appId=cid-v1:xxxxxxxx gehört zu Application Insights, Microsofts Telemetrie-Dienst, und verrät damit gleich zwei Dinge auf einmal: den Stack und das Monitoring-Setup dahinter.
Cookies sind die zweite große Kategorie direkter Spuren, und sie sind oft noch eindeutiger als Header, weil sie an sehr spezifische Frameworks gebunden sind. .AspNetCore.Cookies, .AspNetCore.Antiforgery oder .AspNetCore.Session bedeuten ASP.NET Core, Punkt. ARRAffinity und die zugehörige ARRAffinitySameSite-Variante gehören zum Load Balancing von Azure App Service. ai_user und ai_session stammen vom Browser-SDK von Application Insights. Und ein Cookie namens idsrv deutet auf Duende IdentityServer oder dessen Vorgänger hin, den De-facto-Standard für Identity- und Auth-Server im .NET-Ökosystem.
Bei den Pfaden und Assets wird es noch konkreter, weil hier ganze Frameworks ihre Fingerabdrücke im Verzeichnisbaum hinterlassen. /_framework/blazor.web.js gehört zu Blazor, Microsofts Web-UI-Framework, /_framework/dotnet.js speziell zur WebAssembly-Variante davon, und /_blazor markiert einen Blazor-Server-Endpunkt mit einer dauerhaften SignalR-Verbindung zum Server. Endet ein Pfad auf /negotiate, handelt es sich fast immer um SignalR, Microsofts Echtzeit-Kommunikationsbibliothek. Und wo /swagger oder /openapi.json erreichbar sind, liegt darunter fast immer eine ASP.NET-Core-Web-API, die ihre eigene Dokumentation öffentlich mitliefert.
Eine vierte, oft übersehene Signalquelle ist das Telemetrie-JavaScript selbst. Skripte mit Namen wie ai.2.min.js oder Referenzen auf applicationinsights im Quellcode, Requests an dc.services.visualstudio.com oder an *.in.applicationinsights.azure.com, der traceparent-Header nach dem W3C-Trace-Context-Standard, und ein globales window.appInsights-Objekt im Browser-Kontext: All das läuft unter der Haube, sobald eine Seite Application Insights zum Monitoring einsetzt, und ist mit den Bordmitteln jedes Browsers sichtbar.
Indirekte Spuren: DNS und Zertifikat
Wo direkte Spuren fehlen, hilft ein Blick auf die Infrastruktur dahinter. Ein CNAME-Eintrag, der auf eine Subdomain unter azurewebsites.net zeigt, verrät App Service, azure-api.net steht für API Management, azurefd.net für Azure Front Door, blob.core.windows.net für Blob Storage und azureedge.net für das CDN. Auch ein TLS-Zertifikat kann sprechen: Taucht im Subject Alternative Name eine interne azurewebsites.net-Subdomain auf, die eigentlich nicht für die Öffentlichkeit gedacht war, ist das ein klarer Hinweis auf die zugrunde liegende Hosting-Plattform, unabhängig davon, welcher Domainname vorne im Browser steht.
Verhaltens-Signale: wie der Server auf Fehler reagiert
Manchmal verrät sich ein Stack nicht durch das, was er sendet, sondern durch das, wie er auf Fehler reagiert. Eine 400er-Antwort im ProblemDetails-Format nach RFC 7807, erkennbar am charakteristischen JSON mit den Feldern type, title, status und detail, ist das Standard-Fehlerformat von ASP.NET Core. Ein Endpunkt unter /health oder /healthz, der mit dem einzelnen Wort „Healthy“ antwortet, folgt der Namenskonvention der .NET-Health-Checks-Bibliothek.
Der wichtigste Punkt in dieser Kategorie ist aber keine reine Erkennungshilfe, sondern ein eigenständiges Sicherheitsproblem: eine öffentlich erreichbare Developer-Exception-Page. Diese Seite ist in ASP.NET Core standardmäßig für die Entwicklungsumgebung gedacht und zeigt im Fehlerfall den vollständigen Stacktrace, interne Dateipfade und teilweise sogar Umgebungsvariablen an. Landet sie versehentlich in der Produktion, verrät sie nicht nur den Stack, sondern liefert einem Angreifer eine Bauanleitung für die eigene Infrastruktur frei Haus. Wer diese Seite bei einem eigenen Dienst öffentlich erreichbar findet, sollte das nicht als Kuriosität behandeln, sondern als High-Finding in jedem ernst gemeinten Bericht.
Klartext für Techniker: Die Developer-Exception-Page lässt sich mit einer einzigen Zeile in Program.cs abschalten (app.UseExceptionHandler statt app.UseDeveloperExceptionPage() außerhalb der Development-Umgebung). Trotzdem taucht sie in der Praxis immer wieder produktiv auf, meist weil eine Umgebungsvariable falsch gesetzt ist oder ein Staging-Deployment versehentlich zum Live-System wurde.
Wie sicher ist ein Fund wirklich? Die vier Stufen
Nicht jedes Signal ist gleich viel wert, und genau hier passiert der häufigste Fehler bei technischer Bestandsaufnahme: ein einzelnes schwaches Indiz wird als Gewissheit verkauft. Vier Stufen helfen, das sauber zu trennen.
Sicher ist ein Fund, wenn ein einzelnes Signal keine andere Erklärung zulässt. Das Cookie .AspNetCore.Cookies gehört in diese Kategorie: Es existiert nur, wenn ASP.NET Core Authentication tatsächlich läuft.
Stark indiziert ist ein Fund, wenn mehrere unabhängige Signale in dieselbe Richtung zeigen, aber theoretisch auch anders erklärbar wären. Ein ARRAffinity-Cookie zusammen mit einem CNAME auf eine azurewebsites.net-Domain ergibt zusammen ein sehr stimmiges Bild, auch wenn keines der beiden Signale für sich allein hundertprozentig wäre.
Bloße Vermutung ist ein Fund, wenn sich eine Website wie eine typische ASP.NET-Core-Anwendung verhält, ohne dass ein einziger harter Marker auftaucht, kein passendes Cookie, kein verräterischer Header. Solche Vermutungen gehören in einen Bericht, aber klar als Vermutung gekennzeichnet, nicht als Tatsache formuliert.
Intern bestätigt ist die höchste Stufe, aber sie erfordert einen Blick hinter die Fassade, der von außen gar nicht möglich ist: Ein Eintrag wie Microsoft.ApplicationInsights.AspNetCore in der .csproj-Datei des Projekts belegt den Stack zweifelsfrei, setzt aber internen Zugriff auf den Quellcode voraus. Für externe Betrachter bleibt diese Stufe unerreichbar, und genau das ist der entscheidende Unterschied zu den ersten drei Stufen.
Klartext für Geschäftsführer: Wenn Ihnen jemand sagt „Ihre Seite läuft auf Azure“, fragen Sie nach, worauf sich das stützt. Ein Cookie-Name ist ein Beweis. Ein „sieht danach aus“ ist eine Meinung. Der Unterschied entscheidet darüber, ob eine Aussage in einem Bericht Gewicht hat oder nicht.
Die Grenze, die zählt: nur passiv, nie ohne Freigabe
Alle bisher genannten Signale lassen sich beobachten, ohne einen einzigen ungewöhnlichen Request abzusetzen. Ein Header lesen, ein Cookie im Browser ansehen, einen DNS-Eintrag abfragen, eine ohnehin öffentlich erreichbare Seite mit ihrem regulären Aufruf laden: Das sind passive, nicht-invasive Checks, die technisch nicht anders aussehen als ein gewöhnlicher Website-Besuch.
Damit endet aber auch die Grenze dessen, was ohne Zustimmung des Betreibers vertretbar ist. Wer testet, ob ein /swagger-Endpunkt existiert, bewegt sich noch im passiven Bereich. Wer beginnt, Pfade systematisch durchzuprobieren, Authentifizierung zu umgehen oder gezielt nach ausnutzbaren Schwachstellen zu suchen, verlässt diesen Bereich und braucht eine ausdrückliche Freigabe des Betreibers. Brute-Forcing, Fuzzing oder gar der Versuch, eine erkannte Schwäche tatsächlich auszunutzen, sind ohne diese Freigabe nicht bloß eine Stilfrage, sondern strafrechtlich relevant. Diese Grenze gilt unabhängig davon, wie interessant ein gefundenes Signal aussieht.
Was das für die eigene Website bedeutet
Wer diese Signale kennt, kann sie an der eigenen Infrastruktur gegenprüfen. Bei vielen Unternehmens-Webseiten, die auf Azure App Service laufen, reicht schon ein Blick in die Browser-Entwicklertools, um ARRAffinity, einen x-azure-ref-Header und mitunter sogar den Application-Insights-Instrumentation-Key im Quelltext zu finden, ganz ohne dass jemand danach gesucht hätte. Keines dieser Signale ist für sich genommen ein Sicherheitsproblem, aber in der Summe zeichnen sie ein Bild der eingesetzten Technik, das nicht jeder Betreiber bewusst so öffentlich stehen lassen wollte. Wer die eigene Angriffsfläche kennt, kann selbst entscheiden, welche Header verzichtbar sind und welche Fehlerseite in der Produktionsumgebung wirklich nichts zu suchen hat.
Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 26.07.2026. Aktives Testen fremder Systeme ohne Zustimmung des Betreibers kann strafrechtlich relevant sein (§ 202a ff. StGB).









