TL;DR: Das Wichtigste
- Ein Sicherheits-Header für HTTP ist eine Anweisung, die der Server mit jeder Seite an den Browser sendet. Der Browser wendet diese anschliessend an, um den Besucher zu schützen: Er sorgt dafür, dass die Verbindung über HTTPS aufrechterhalten bleibt, wehrt nicht autorisierte Skripte ab, verhindert die Darstellung der Website in einem unsichtbaren Frame und schränkt die an Drittanbieter-Websites übermittelten Informationen ein.
- Diese Massnahmen werden auf dem Webserver, dem Reverse-Proxy oder dem CDN konfiguriert, ohne den Inhalt der Website zu verändern. Dies ist eine der kosteneffizientesten Lösungen für die Websicherheit.
- Es lassen sich drei Bereiche unterscheiden: die Sicherung der Datenübertragung (HTTPS, Weiterleitung, HSTS), die Kontrolle darüber, was die Seite ausführen darf (CSP, nosniff, Anti-Clickjacking) und die Eindämmung von Informationslecks (Referrer-Policy, Permissions-Policy, Softwareversion, Cookies).
- Die meisten Sicherheits-Header lassen sich innerhalb weniger Stunden implementieren. Die Content-Security-Policy (CSP) bildet hier eine Ausnahme: Sie erfordert eine Bestandsaufnahme der Skripte und eine schrittweise Einführung.
- Die Header beheben keine Sicherheitslücken. Sie mindern die Auswirkungen bestehender oder künftiger Sicherheitslücken und stellen ein Zeichen der Reife dar, das von aussen für jeden sichtbar ist – auch für einen Angreifer.
Die öffentliche Website einer Organisation ist oft ihr am stärksten gefährdetes IT-Asset. Sie wird von Tausenden von Besuchern aufgerufen, stützt sich auf Skripte von Drittanbietern (Besucherzähler, Karten, Formulare, Chat) und ist jederzeit und von überall aus zugänglich. Wird eine Sicherheitslücke ausgenutzt – sei es durch eine Skript-Injektion, eine Klick-Umleitung oder das Abfangen einer Sitzung –, so ist in erster Linie der Besucher davon betroffen.
Mithilfe von HTTP-Sicherheits-Headers lässt sich der Browser zu einem Verbündeten machen. Mit nur wenigen Zeilen Konfiguration teilt der Server ihm mit, was er akzeptieren und was er ablehnen soll. Dieser Leitfaden erläutert, wozu jeder dieser Header dient, wie sie zusammenwirken und welche Entscheidungen sie für einen Sicherheitsbeauftragten oder eine Führungskraft mit sich bringen. Es handelt sich hierbei nicht um ein Konfigurationshandbuch, sondern um einen Rahmen zum Verständnis und zur Entscheidungsfindung.
Ein Sicherheits-Header für HTTP verwandelt den Browser in einen Schutzagenten
Jedes Mal, wenn ein Browser eine Seite anfordert, antwortet der Server in zwei Schritten: Zunächst folgt eine Reihe von Header-Zeilen, die für den Besucher nicht sichtbar sind, anschliessend der Inhalt der Seite. Diese Sicherheits-Header für HTTP beschreiben die Antwort (Dateityp, Datum, Grösse) und können zudem Sicherheitsanweisungen übermitteln.
L'essentiel Cybersécurité, IA & Tech
Rejoignez la communauté. 3 fois par semaine, recevez l'analyse des tendances par Marc Barbezat. Pas de spam, juste de l'info.
Ein Sicherheits-Header für HTTP ist eine Anweisung, die der Server mit jeder Seite an den Browser sendet und die der Browser anschliessend im Namen des Besuchers umsetzt. Er kann den Besucher beispielsweise anweisen, niemals über eine unverschlüsselte Verbindung zurückzukehren, nur Skripte aus angegebenen Quellen auszuführen, den Dateityp nicht zu erraten, die Darstellung der Website in einem unsichtbaren Frame zu verweigern oder die an Drittanbieter übermittelten Daten zu beschränken.
Ihre Bedeutung beruht auf drei Merkmalen.
Sie lassen sich konfigurieren, ohne dass Änderungen an der Website vorgenommen werden müssen. Die Sicherheits-Header werden auf dem Webserver, dem Reverse-Proxy, der Anwendungsfirewall oder dem CDN eingestellt. Der Inhalt, der Code und das Design der Website bleiben unverändert.
Sie greifen dort ein, wo die Organisation keinen Einfluss mehr hat. Sobald die Seite gesendet wurde, wird sie auf dem Rechner des Besuchers ausgeführt. Sicherheits-Header von HTTP sind die einzige Möglichkeit, an dieser Stelle weiterhin Regeln festzulegen.
Sie sind von aussen sichtbar. Jeder kann die Header einer Website innerhalb weniger Sekunden auslesen. Ihr Vorhandensein oder Fehlen gibt daher Aufschluss über die Sorgfalt der Organisation, was für einen Prüfer ebenso von Interesse ist wie für einen Angreifer in der Erkundungsphase.
Drei Gruppen von Überschriften entsprechen drei Risikogruppen
Die allgemein empfohlenen HTTP-Sicherheits-Header lassen sich in drei Gruppen einteilen, von denen jede eine andere Frage beantwortet.
| Familie | Frage | Überschriften und Massnahmen |
|---|---|---|
| Transport | Ist die Verbindung verschlüsselt, und bleibt sie auch weiterhin verschlüsselt? | HTTPS, Weiterleitung zu HTTPS, HSTS |
| Ausführung | Was darf die Seite laden und ausführen? | Content-Security-Policy, X-Content-Type-Options, X-Frame-Options |
| Informationslecks | Welche Informationen gibt die Website an Dritte oder Angreifer weiter? | Referrer-Policy, Permissions-Policy, Versionsverschleierung, Cookie-Attribute |
HTTPS, Weiterleitung und HSTS sichern die Datenübertragung
HTTPS ist die Grundvoraussetzung für alles Weitere
Ohne HTTPS kann alles, was zwischen dem Besucher und der Website ausgetauscht wird, unterwegs gelesen oder verändert werden: Anmeldedaten, Formulardaten, Sitzungs-Cookies. Ein Angreifer, der sich im selben öffentlichen WLAN-Netzwerk befindet oder in der Lage ist, den Datenverkehr abzufangen, kann zudem Inhalte in die Seiten einschleusen. Kein anderer Header hat eine Bedeutung, wenn die Verbindung selbst nicht verschlüsselt ist, da ein Angreifer diese einfach löschen könnte.
Angesichts der zunehmenden Verbreitung kostenloser und automatisierter Zertifikate gibt es heute weder technische noch wirtschaftliche Gründe, auf HTTPS zu verzichten.
Durch die Weiterleitung wird die unverschlüsselte Verbindung geschlossen
Ein Besucher, der eine Adresse eingibt, ohne https:// gelangt zunächst auf die unverschlüsselte Version der Website. Der Server muss ihn dann unverzüglich und dauerhaft auf die verschlüsselte Version umleiten. Ohne diese Umleitung bleibt der erste Datenaustausch unverschlüsselt, und genau diesen ersten Datenaustausch kann ein Angreifer abfangen.
Der Unterschied zwischen einer permanenten und einer temporären Weiterleitung ist kein Nebengedanke: Eine temporäre Weiterleitung veranlasst den Browser, bei späteren Besuchen erneut die unverschlüsselte Version aufzurufen.
HSTS unterbindet den ersten unverschlüsselten Datenaustausch
Die Umleitung weist eine Schwachstelle auf: Sie erfolgt erst nach einer ersten unverschlüsselten Anfrage. HSTS (HTTP Strict Transport Security), standardisiert durch die IETF (RFC 6797), behebt diese Schwachstelle. Dieser Header weist den Browser an, dass er für einen bestimmten Zeitraum die Website ausschliesslich über HTTPS aufrufen darf, selbst wenn der Besucher die Adresse ohne Präfix eingibt oder einem alten Link folgt, der http://.
Zwei Parameter verdienen die Aufmerksamkeit eines Entscheidungsträgers. Zunächst die Laufzeit: Ein Wert von einem Jahr dient als Richtwert; eine zu kurze Laufzeit führt dazu, dass die Einstellung zwischen zwei Besuchen abläuft. Als Nächstes die Ausweitung auf Subdomains (Option includeSubDomains), die den Schutz verstärkt, jedoch voraussetzt, dass alle Subdomains, einschliesslich der ältesten oder am meisten in Vergessenheit geratenen, über HTTPS erreichbar sind.
Browser führen zudem eine HSTS-Vorladeliste: Eine darin aufgeführte Domain ist bereits beim allerersten Besuch geschützt. Die Aufnahme in diese Liste ist eine verbindliche Entscheidung. Sie gilt für alle Subdomains, und die Entfernung aus der Liste dauert Monate, da es so lange dauert, bis neue Browserversionen veröffentlicht werden.
CSP, nosniff und Anti-Clickjacking regeln, was auf der Seite ausgeführt wird
CSP begrenzt die Auswirkungen einer Code-Injektion
Das Cross-Site-Scripting (XSS) ist nach wie vor eine der häufigsten Sicherheitslücken im Web. Es ermöglicht einem Angreifer, eigenen Code auf der vom Besucher angezeigten Seite ausführen zu lassen: Session-Diebstahl, Erfassung von Eingaben, Weiterleitung zu einem gefälschten Zahlungsformular.
Die Content-Security-Policy (CSP) reduziert diese Auswirkungen erheblich. Sie übermittelt dem Browser eine Liste der zulässigen Quellen für Skripte, Stylesheets, Bilder oder Formulare. Alles, was nicht in dieser Liste aufgeführt ist, wird blockiert, einschliesslich eines von einem Angreifer eingeschleusten Skripts.
Dies ist der leistungsstärkste Header, dessen Implementierung jedoch am schwierigsten ist. Eine moderne Website lädt oft Dutzende externer Ressourcen: Tag-Manager, Zugriffsmessung, Videos, Schriftarten, Marketing-Tools. Eine zu strenge Richtlinie beeinträchtigt die Funktionalität; eine zu freizügige Richtlinie, die beispielsweise alle in die Seite eingebetteten Skripte zulässt (unsafe-inline), bietet nur noch einen Scheinschutz.
Die bewährte Vorgehensweise besteht darin, zunächst im Berichtsmodus zu beginnen (Content-Security-Policy-Report-Only): Der Browser meldet Verstösse, ohne etwas zu blockieren. Das Unternehmen beobachtet die Situation, passt seine Liste an und wechselt anschliessend in den Durchsetzungsmodus. Ähnlich wie bei DMARC in der E-Mail-Sicherheit besteht die Gefahr, auf unbestimmte Zeit im Beobachtungsmodus zu verbleiben, der niemanden schützt.
Für Entscheidungsträger wirft die CSP eine umfassendere Frage der Unternehmensführung auf: Wer entscheidet über die auf der Website hinzugefügten Skripte von Drittanbietern? Jedes ohne Überprüfung hinzugefügte Marketing-Tool vergrössert die Angriffsfläche und erschwert die Umsetzung der Richtlinien. Die Zahlungsbranche hat dies sehr wohl verstanden: Seit März 2025 verlangt der PCI-DSS-Standard 4.0 von Händlern eine Bestandsaufnahme und Genehmigung der auf den Zahlungsseiten vorhandenen Skripte sowie die Erkennung unbefugter Änderungen an diesen Seiten und deren Sicherheits-Header.
nosniff verhindert, dass der Browser die Art des Geräts errät
Browser haben lange Zeit versucht, den tatsächlichen Dateityp zu erraten, wenn der Server diesen falsch angab. Dieser „gute Wille“ kann ausgenutzt werden: Eine als Bild oder Text hochgeladene Datei kann als Skript interpretiert und ausgeführt werden. Der Header „X-Content-Type-Options: nosniff“ verhindert diese Interpretation. Der Browser hält sich an den vom Server angegebenen Typ. Dies ist eine einfache Massnahme, die auf einer korrekt konfigurierten Website keine Nebenwirkungen hat.
Der Clickjacking-Schutz verhindert die Anzeige in einem unsichtbaren Frame
Beim Clickjacking (Klick-Manipulation) wird die legitime Website in einem transparenten Rahmen angezeigt, der über eine manipulierte Seite gelegt ist. Der Internetnutzer glaubt, auf eine harmlose Schaltfläche zu klicken; tatsächlich bestätigt er jedoch eine Aktion auf der legitimen Website, auf der er möglicherweise bereits angemeldet ist.
Zwei Mechanismen wirken dem entgegen. Der historische Header „X-Frame-Options“ verbietet oder schränkt die Darstellung der Website in einem Frame ein. Die CSP-Direktive „frame-ancestors“ tut dasselbe auf raffiniertere Weise und hat in neueren Browsern Vorrang, wenn beide vorhanden sind. Die Kombination beider Massnahmen wird weiterhin empfohlen, um auch ältere Browser abzudecken.
Referrer-Policy, Permissions-Policy, Version und Cookies begrenzen Datenlecks
Die Referrer-Policy regelt, welche Informationen an ausgehende Links weitergegeben werden
Wenn ein Besucher auf einen Link zu einer anderen Website klickt, übermittelt sein Browser in der Regel die Adresse der Ursprungsseite. Diese Adresse kann sensible Informationen enthalten: Ordner-IDen, Suchparameter, Tokens zum Zurücksetzen des Passworts. Der Header „Referrer-Policy“ legt fest, welche Informationen übermittelt werden. Der Wert strict-origin-when-cross-origin, der heute von den gängigsten Browsern standardmässig verwendet wird, übermittelt an Dritte lediglich den Namen der Website. Eine explizite Angabe dieses Werts gewährleistet ein einheitliches Verhalten unabhängig vom verwendeten Browser.
„Permissions-Policy“ deaktiviert nicht benötigte Browserfunktionen
Kamera, Mikrofon, Standortbestimmung, Zahlungsfunktionen: Moderne Browser gewähren Webseiten Zugriff auf zahlreiche Funktionen. Mithilfe des Header-Feldes „Permissions-Policy“ lassen sich die Funktionen angeben, die die Website tatsächlich nutzt, und alle anderen deaktivieren. Sollte es einem bösartigen Skript gelingen, ausgeführt zu werden, kann es diese Funktionen nicht aufrufen. Für eine institutionelle Website, die weder Kamera noch Standortbestimmung nutzt, ist diese Massnahme unmittelbar wirksam und mit keinerlei Nachteilen verbunden.
Das Verbergen der Softwareversion nimmt dem Angreifer eine Abkürzung
Zahlreiche Server geben von sich aus ihre Software und deren genaue Version an (Webserver, Programmiersprache). Diese Information ermöglicht es einem Angreifer oder einem automatisierten Tool, direkt nach bekannten Sicherheitslücken dieser Version zu suchen. Das Verbergen der Version behebt das Problem nicht und ersetzt nicht die Installation von Patches. Es zwingt den Angreifer jedoch dazu, mehr Aufwand zu betreiben, und verhindert, dass eine Website bei automatisierten Suchvorgängen nach anfälligen Versionen auftaucht.
Die Eigenschaften von Cookies dienen dem Schutz von Sitzungen
Cookies enthalten häufig die Sitzungs-ID des Besuchers. Drei Attribute, die in dem Header übermittelt werden, der sie erstellt, bestimmen deren Sicherheit:
- Sicher: Das Cookie wird niemals über eine unverschlüsselte Verbindung gesendet;
- HttpOnly: Das Cookie kann von einem Skript nicht gelesen werden, wodurch die Auswirkungen einer Injektion begrenzt werden;
- SameSite: Das Cookie wird bei Anfragen, die von anderen Websites initiiert werden, nicht übermittelt, wodurch das Risiko von Manipulationen bei Anfragen (CSRF) verringert wird.
Ein Session-Cookie ohne diese Attribute ist ein bevorzugtes Ziel für alle, die versuchen, sich als ein Benutzer auszugeben.
Einige Kopfzeilen sind inzwischen veraltet
Die Liste der empfohlenen Header-Zeilen unterliegt ständigen Änderungen. Einige Mechanismen, die in früheren Leitfäden häufig erwähnt wurden, sollten heute nicht mehr verwendet werden.
X-XSS-Protection aktivierte einen in älteren Browsern integrierten Anti-Injection-Filter. Dieser Filter wurde aus modernen Browsern entfernt, da er selbst Sicherheitslücken verursachen konnte. Derzeit wird empfohlen, ihn nicht mehr zu verwenden oder ihn ausdrücklich zu deaktivieren; die CSP hat diese Funktion übernommen.
Mit Public-Key-Pins (HPKP) konnten die für eine Website erwarteten Zertifikate festgelegt werden. Das Risiko, eine Website versehentlich unzugänglich zu machen, war jedoch so gross, dass die Browser diese Funktion aufgegeben haben.
Expect-CT diente dazu, die Transparenz von Zertifikaten zu erzwingen, die nun standardmässig von den Browsern vorgeschrieben wird. Es hat keinen Nutzen mehr.
Das Vorhandensein dieser Kopfzeilen auf einer Website ist an sich kein Problem, deutet jedoch häufig darauf hin, dass die Konfiguration aus einem älteren Leitfaden kopiert und nie überarbeitet wurde.
Die Überschriften ersetzen keine anderen Massnahmen
HTTP-Sicherheits-Header stellen eine zusätzliche Schutzebene dar, sind jedoch keine Lösung. Dabei sind vier Einschränkungen zu beachten.
Sie mindern die Auswirkungen von Sicherheitslücken, beheben diese jedoch nicht. Eine CSP schränkt die Möglichkeiten eines eingeschleusten Skripts ein; sie beseitigt jedoch nicht die Sicherheitslücke, die das Einschleusen ermöglicht hat. Sichere Entwicklung, Patch-Management und Tests bleiben unverzichtbar.
Sie schützen nur Besucher, deren Browser diese Funktionen unterstützt. Ein veralteter Browser oder ein automatisiertes Tool kann sie ignorieren.
Sie müssen alle Seiten abdecken. Eine Kopfzeile, die auf der Startseite konfiguriert ist, aber auf Anmeldeseiten, Formularseiten oder Subdomains fehlt, lässt die sensibelsten Bereiche ungeschützt.
Über den Rest der Infrastruktur verlieren sie kein Wort. Eine Website, deren Kopfzeilen einwandfrei sind, kann dennoch auf einem nicht ordnungsgemäss gepatchten Server, einer schwachen TLS-Konfiguration oder einer anfälligen Anwendung basieren.
Sicherheits-Header in sechs Schritten implementieren
Die meisten HTTP-Sicherheits-Header lassen sich innerhalb eines Tages implementieren. Der grösste Aufwand entfällt auf die CSP und auf die Organisation, die sicherstellt, dass die Konfiguration beibehalten wird.
- Erstellen Sie eine Bestandsaufnahme der betroffenen Websites, einschliesslich derjenigen, die bei Drittanbietern gehostet werden, sowie der Subdomains und Kampagnen-Websites.
- Umsetzung der Sofortmassnahmen: HTTPS überall, permanente Weiterleitung, HSTS für ein Jahr, nosniff, Anti-Clickjacking, Referrer-Policy, Permissions-Policy, Ausblendung der Cookie-Version und der Cookie-Attribute.
- Die Konfiguration sollte, soweit möglich, zentralisiert werden (Reverse-Proxy, CDN, Anwendungsfirewall), um für alle Websites und Seiten dieselben Regeln anzuwenden.
- Schrittweise Einführung der CSP: zunächst im Berichtsmodus, dann Analyse der Verstösse, Reduzierung von Skripten von Drittanbietern und schliesslich im Anwendungsmodus.
- Nehmen Sie diese Anforderungen in die Verträge mit Webagenturen und Hosting-Anbietern auf, damit jede neue Website mit diesen Kopfzeilen bereitgestellt wird und deren Beibehaltung überprüfbar ist.
- Langfristige Überwachung: Ein Server-Update, ein Wechsel des CDN oder eine Neugestaltung reichen aus, um einen Header verschwinden zu lassen, ohne dass es jemand bemerkt.
Häufig gestellte Fragen zu HTTP-Sicherheits-Headers
Was ist ein HTTP-Sicherheits-Header?
Es handelt sich um eine Anweisung, die der Server mit jeder Seite an den Browser übermittelt und die der Browser anschliessend zum Schutz des Besuchers umsetzt. Sie kann die Beibehaltung von HTTPS vorschreiben (HSTS), die zulässigen Skripte einschränken (CSP), die Neuinterpretation des Dateityps untersagen (nosniff), die Anzeige der Website in einem unsichtbaren Frame blockieren, die an Websites von Drittanbietern übermittelten Informationen einschränken (Referrer-Policy) oder den Zugriff auf Browserfunktionen (Permissions-Policy) einschränken. Diese Anweisungen werden auf dem Webserver konfiguriert, ohne den Inhalt der Website zu verändern.
Welche Sicherheits-Header sollten vorrangig behandelt werden?
HTTPS, die permanente Weiterleitung zu HTTPS und HSTS stehen an erster Stelle, da sie die Wirksamkeit aller anderen Massnahmen bedingen. Es folgen einfache Massnahmen ohne Nebenwirkungen: Nosniff, Anti-Clickjacking, Referrer-Policy, Permissions-Policy, Versionsmaskierung und Cookie-Attribute. Die CSP, die zwar leistungsfähiger, aber auch anspruchsvoller ist, wird anschliessend schrittweise eingeführt.
Warum ist die Umsetzung der CSP so schwierig?
Weil dadurch alle von der Website verwendeten Skript- und Ressourcenquellen angegeben werden müssen. Auf einer Website, auf der zahlreiche Tools von Drittanbietern zum Einsatz kommen (Besucheranalyse, Marketing, Videos, Chat), ist diese Bestandsaufnahme sehr umfangreich, und jede Auslassung führt zum Ausfall einer Funktion. Im Berichtsmodus können Sie Verstösse erkennen, bevor Sie irgendetwas blockieren.
Ersetzen Sicherheits-Header eine Anwendungs-Firewall oder Patches?
Nein. Die Header mindern die Auswirkungen einer Sicherheitslücke auf der Browserseite; sie beheben diese jedoch nicht und wehren auch keine Angriffe ab, die direkt auf den Server abzielen. Sie ergänzen die sichere Entwicklung, das Patch-Management und die Anwendungsfirewall, die im Übrigen dazu dienen kann, sie zentral anzuwenden.
Sollte man seine Domain in die HSTS-Vorladeliste aufnehmen?
Dies ist der umfassendste Schutz, da die Website bereits ab dem ersten Besuch geschützt ist. Diese Entscheidung ist jedoch langfristig bindend: Alle Subdomains müssen über HTTPS erreichbar sein, und eine Streichung aus der Liste dauert mehrere Monate. Diese Option ist daher nur für Organisationen geeignet, die den vollständigen Überblick über ihre Subdomains haben.
Ist der Header „X-XSS-Protection“ noch sinnvoll?
Nein. Der Filter, den er aktivierte, wurde aus modernen Browsern entfernt und konnte eigene Sicherheitslücken verursachen. Die aktuelle Empfehlung lautet, ihn nicht mehr zu verwenden oder ihn ausdrücklich zu deaktivieren und stattdessen auf die CSP zurückzugreifen.
Wer ist für die Konfiguration der Kopfzeilen zuständig, wenn die Website von einem Dienstleister verwaltet wird?
Die Organisation bleibt für die Sicherheit ihrer Websites verantwortlich, auch wenn diese von einem Dritten entwickelt oder gehostet werden. Die erforderlichen Header müssen im Lastenheft und im Vertrag aufgeführt sein, und es muss eine Möglichkeit bestehen, zu überprüfen, ob sie nach jedem Update weiterhin vorhanden sind.
Weitere Informationen zu diesem Thema
Projet OWASP Secure Headers | Fondation OWASP
Le projet OWASP Secure Headers (OSHP) décrit les en-têtes de réponse HTTP que votre application peut utiliser pour améliorer sa sécurité. Lire la suite
En-têtes HTTP – Fiches récapitulatives OWASP
Site web regroupant toutes les fiches récapitulatives du projet. Lire la suite
En-tête Content-Security-Policy (CSP) – HTTP
L'en-tête de réponse HTTP Content-Security-Policy permet aux administrateur·ice·s d'un site web de contrôler les ressources que l'agent utilisateur est autorisé à charger pour une page donnée. Lire la suite
En-tête Strict-Transport-Security – HTTP
L'en-tête de réponse HTTP Strict-Transport-Security (HSTS) indique aux navigateurs que l'hôte ne doit être accessible que via HTTPS et que toute tentative d'accès ultérieure via HTTP sera automatiquement redirigée vers HTTPS. De plus, lors des connexions ultérieures à l'hôte, le… Lire la suite
RFC 6797 : Sécurité stricte du transport HTTP (HSTS) | Éditeur de RFC
Cette spécification définit un mécanisme permettant aux sites web de se déclarer accessibles uniquement via des connexions sécurisées et/ou aux utilisateurs de configurer leur navigateur pour interagir avec ces sites uniquement via des connexions sécurisées. Cette politique globale est appelée… Lire la suite
Serveurs, API, temps de veille...
DCOD est indépendant et sans revenus. Soutenez le site pour l'aider à couvrir ses frais techniques.
