Sicherheit ist immer ein zweischneidiges Schwert, oder ein dreischneidiges…
Der Level der implementierten Sicherheitsmassnahmen ist abhängig von der Notwendigkeit, der Sicherheitsmassnahmen an sich und der Bequemlichkeit:
Notwendigkeit meint u.a. behördliche oder gesetzliche Anforderungen. Massnahmen sind die zu implementierenden Sicherheitsfunktionen, und die Bequemlichkeit muss ich an dieser Stelle nicht näher erläutern.
Das trifft ganz speziell bei den HTTP Security Headers zu. Einige Massnhamen erachte ich als absolut notwendig, einige als nicht unbedingt nötig oder sogar gefährlich.
Mit wenig Aufwand lässt sich der Sicherheitslevel jedoch beträchtlich steigern, sofern man nicht zu bequem ist, sich mit dem Thema auseinander zu setzen. Dass Du diesen Blogbeitrag liest entlastet dich sofort vom Vorwurf der Bequemlichkeit 😉.
Inhalt
1. Security-Header: Warum eigentlich?
2. X-Content-Type-Options – Kein MIME-Sniffing
3. X-Frame-Options – Schluss mit Clickjacking
4. Referrer-Policy: was der Browser erzählt
5. CORS – Wer darf mitspielen?
6. CORP – Wer darf mitlesen?
7. HSTS – HTTPS oder gar nicht!
8. Subresource Integrity – auch extern geschützt!
9. Permission Policy
10. Cookies – Nur mit Sicherheitsgurt
11. Content Security Policy – Jetzt wird’s kompliziert
12. Fehler identifizieren
13. Zwischen Anspruch und Alltag: Zeit für ein Fazit
14. Bonus: „Low hanging headers“ zum kopieren
1. Security-Header: Warum eigentlich?
Stell dir vor, deine Website ist dein Zuhause. Die .htaccess ist deine Tür. Und ohne Tür? Na ja – dann kann jeder reinkommen und sich benehmen, wie er lustig ist.
Security Headers sind kleine, aber mächtige Regeln, die in die .htaccess-Datei geschrieben und von deinem Server an den Browser geschickt werden. Die sagen ihm, wie er sich zu verhalten hat. Sie schützen vor Clickjacking, XSS, CSRF und anderen digitalen Gemeinheiten. Die Fachsimpelei wird im jeweiligen Abschnitt in deutscher Sprache erläutert 🤓.
Mächtig, aber kaum genutzt
Laut einer Analyse von über 45 Millionen mehrfach gescannten URLs auf securityheaders.com zeigt sich:
- 95,9 % der Websites behielten dauerhaft eine F-Bewertung – das bedeutet, sie setzen praktisch keine Security Headers ein.
- Nur 1,3 % der Websites erreichten dauerhaft ein A+ – also die höchste Sicherheitsbewertung.
- Etwa 1,3 % der Websites hielten konstant ein A.
- Etwa 1.0% erreichen konstant ein Rating B.
Diese Zahlen verdeutlichen, dass die überwiegende Mehrheit der Websites keine ausreichenden Sicherheitsmaßnahmen durch HTTP Security Headers implementiert hat. Es geht nicht darum, perfektionistisch zu sein. Sondern darum, mit wenig Aufwand deine Website und damit deine Besucher zu schützen.
Warum nutzen sie so wenige?
Die Gründe für die dafür sind vielfältig:
- Unwissenheit („Was ist denn das bitte?“)
- Komplexität
- Plugins & externe Services, die plötzlich blockiert werden
- Frust („Es nimmt kein Ende…“)
- „Man“ kann nicht immer alles machen
- Bequemlichkeit
🧪 Tools zum Testen:
- securityheaders.com: Schnell, direkt, hilfreich
- Mozilla Observatory: Gründlich, nerdig, gnadenlos
Kleiner Aufwand, grosse Wirkung
Die gute Nachricht: Ein ansprechendes Sicherheitslevel ist absolut drin – auch ohne ausgefeilte Content Security Policy (CSP).
👉 In diesem Beitrag zeige ich dir, wie du mit ein paar gezielten Header-Zeilen in deiner .htaccess-Datei schnell und ohne Plugin-Chaos deine Seite deutlich sicherer machst. Ganz ohne JavaScript-Sperenzchen oder Layout-Zerfall. Die Links zu allen jeweiligen Optionen führen zu den MDN Web Docs (Englisch).
Also, legen wir los!
2. X-Content-Type-Options – Kein MIME-Sniffing
💡 Was ist MIME & MIME-Sniffing?
MIME steht für Multipurpose Internet Mail Extensions – klingt alt, ist aber überall. Es sagt dem Browser, was für ein Dateityp gesendet wird: HTML, Bild, Script usw.
MIME-Sniffing bedeutet: Der Browser „rät“ den Typ selbst, wenn der Server nichts oder Unsinn angibt – das kann gefährlich sein. Mit nosniff sagst du: „Nein, Browser, rate nicht. Vertrau mir.“ Damit können XSS-Angriffe reduziert werden..
Header set X-Content-Type-Options "nosniff"
Der Browser soll das, was du ihm gibst, auch als genau das behandeln. Keine Rateversuche, keine Improvisation. Du schickst HTML? Dann wird das nicht als JavaScript interpretiert. Punkt.
Praxisbeispiel Sicherheitlücke
Phishing: Einfügen eines Formulars auf der Opfer-Website zum Abgreifen sensibler Daten wie Kennwörter, Kontodaten oder Kreditkartennummern.
XSS (Cross-Site-Scripting): Serverseitige Aufnahme von Daten (z.B. Skripte mit Schadcode) eines Dritten, ohne deren Inhalt zu prüfen. Diese Daten werden an den Browser des Opfers gesendet und dort ausgeführt.
Mögliche Probleme bei der Implementierung
Kann bei „kreativ“ konfigurierten Servern oder MIME-Typen zu Problemen führen, z. B. wenn ein CSS-File versehentlich als text/plain ausgeliefert wird. Dann wird’s blockiert – und das Layout bricht.
3. X-Frame-Options – Schluss mit Clickjacking
💡 Was ist Clickjacking?
Ein Angreifer lädt deine Seite in einem unsichtbaren Frame und legt fiese Buttons drüber. Der Besucher denkt, er klickt auf was Harmloses – in Wirklichkeit wird im Hintergrund etwas auf deiner Seite ausgelöst.
Header always set X-Frame-Options "SAMEORIGIN"
Oder, wenn du ganz strikt sein willst:
Header always set X-Frame-Options "DENY"Keiner darf deine Seite in ein iFrame laden. Schluss mit UI-Tricksereien, bei denen jemand Buttons überlagert und deine Besucher in eine Falle tappen lässt. Nope, nicht mit uns.
Praxisbeispiel Sicherheitlücke
Clickjacking-Attacken: Nutzer klickten auf unsichtbare Buttons, z.B. „Kaufen“ oder „Zahlung senden“, ohne es zu merken.
Mögliche Probleme bei der Implementierung
Inhalte wie eingebettete Tools, Karten, Shops oder Zahlungspartner (z. B. PayPal) nutzen häufig iFrames – hier musst du gezielt ALLOW-FROM oder Content-Security-Policy: frame-ancestors einsetzen.
4. Referrer-Policy: was der Browser erzählt
💡 Was ist ein Referrer?
Wenn du auf einen Link klickst, sagt dein Browser dem Ziel, von wo du kommst – das ist der Referrer. Die Referrer-Policy regelt, wie viel Info dabei mitgeht.
Header set Referrer-Policy "strict-origin-when-cross-origin"Du entscheidest, ob und wie viel Info beim Linkklicken weitergegeben wird. Die URL, von der jemand kommt, kann Rückschlüsse auf Inhalte geben – und manchmal will man das lieber nicht.
⚠️ Achtung! „strict-origin-when-cross-origin“ ist eigentlich CORS (Cross-Origin Resource Sharing). Das kann je nachdem zu Problemen führen, v.a. wenn du ein CDN in Anspruch nimmst. Um dem zu begegnen, gibt es CORS (Pt. 5), das die Referer-Policy „masschneidern“ kann.
Praxisbeispiel Sicherheitlücke
Es gab Fälle, in denen private Token oder Session-IDs über den Referrer an Dritte übermittelt wurden, z. B. beim Aufruf externer Links direkt nach dem Login.
Mögliche Probleme bei der Implementierung
Manche Affiliate-Programme oder Tracking-Dienste benötigen den vollen Referrer. Einschränkende Richtlinien können hier zu Problemen mit Auszahlungen oder Analytics führen.
5. CORS – Wer darf mitspielen?
CORS, oder Access-Control-Allow-xxx, sorgen dafür, dass bestimmte Resourcen nur von bestimmten Quellen kommen dürfen. Bitte beachte: eine Wildcard (*) zu setzen ist keine gute Idee. Ausserdem spuckt die Verwendung von Wildcard mit der Übetragung von Zugangsdaten eine Fehlermeldung aus.
Header set Access-Control-Allow-Origin "https://deinedomain.de"
Vary: Origin💡 Was heißt CORS?
Cross-Origin Resource Sharing. Eine Sicherheitsmaßnahme im Browser, die regelt, welche Webseiten Inhalte von anderen Domains laden dürfen – z. B. Fonts, Skripte oder APIs.
Standardmäßig ist das streng – CORS lockert das bewusst, aber gezielt.
Praxisbeispiel Sicherheitlücke
Einige Angriffe auf REST-APIs nutzten falsch konfigurierte CORS-Regeln, um sensible Daten mit JavaScript auf fremden Seiten auszulesen.
Mögliche Probleme bei der Implementierung
Wenn du CORS zu offen konfigurierst (* oder unkontrollierte Origins), öffnest du Dritten Tür und Tor. Wenn du es zu eng einstellst, brechen externe APIs oder Fonts ab.
6. CORP – Wer darf mitlesen?
💡 Und was ist CORP dann?
Cross-Origin Resource Policy. Ein noch feinerer Regler als CORS – er sagt: „Diese Ressource darf nur von meiner Seite selbst geladen werden. Nicht von Fremden.“
Hilft z. B. gegen das Ausnutzen deiner Bilder oder Fonts.
Header set Cross-Origin-Resource-Policy "same-origin"Du gibst an, ob deine Ressourcen (z.B. Bilder, Schriften) von anderen Domains geladen werden dürfen. Weil du ja nicht willst, dass deine Schriftarten auf fremden Seiten dein Budget belasten…
⚠️ Achtung! CORP kann ebenfalls gegen Hotlinking eingesetzt werden, allerdings nicht so granular (siehe meinen Beitrag dazu). Wenn Du ein CDN verwendest, solltest Du stattdessen Hotlinking verwenden.
Praxisbeispiel Sicherheitlücke
Sicherheitsforscher konnten private Inhalte (z. B. PDFs, Medien) per Pixelstealing extrahieren, indem sie sie von fremden Seiten einbetteten.
Mögliche Probleme bei der Implementierung
Embeds oder Fonts von Drittseiten (z. B. CDN, Tracking-Tools) laden nicht mehr, wenn du versehentlich same-origin aktivierst und nicht cross-origin.
7. HSTS – HTTPS oder gar nicht!
💡 Was ist HTTPS eigentlich?
HSTS heisst HTTP Strict Transport Security und macht nichts anderes, als sicherzustellen, dass die Website als https:// ausgeliefert wird.
HyperText Transfer Protocol Secure – also verschlüsseltes Internet. Nur so bleiben Daten privat, und niemand kann unterwegs mitlesen oder manipulieren. Wenn’s um Formulare, Logins oder Cookies geht: Pflicht.
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"Du hast in deiner -htaccess-Datei bereits einen Redirect auf https:// eingerichtet:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Brauchst du denn HSTS noch zusätzlich? Die Antwort ist ja.
Warum? Bei HSTS merkt sich der Browser für die angegebene Zeit in Sekunden (hier max-age=63072000, entspricht einem Jahr) dass er nur die https://-Version deiner Seite besuchen darf. Während dem ersten Besuch deiner Seite ist HSTS jedoch anfällig für Man-in-the-middle Attacken. Und hier kommt der Redirect in’s Spiel, der das Problem abfängt.
Andererseits: falls jemand auf ein Bild deiner Seite verlinkt (z.B. http://deine.domain/bild.jpg) – bekannt als gemischte Inhalte – wird dies vom Redirect NICHT abgefangen, von HSTS aber schon.
⚠️ Achtung! Sei vorsichtig mit preload! Man kann seine Seite für Preloading (https://hstspreload.org) anmelden (unter gewissen Voraussetzungen), kriegt diese aber fast nicht mehr runter! Beispiel: falls du deine Seite zu einem neuen Hosting Provider umziehst und https:// (noch) nicht eingerichtet ist, wirst du deine Seite nicht mehr erreichen können.
Praxisbeispiel Sicherheitlücke
Man-in-the-Middle-Angriffe über öffentliche WLANs (z. B. in Hotels/Cafés), bei denen der erste HTTP-Aufruf abgefangen und manipuliert wurde – HSTS verhindert das zuverlässig (!NACH dem ersten Besuch der Website! -> darum auch zusätzlich den http -> https Redirect).
Mögliche Probleme bei der Implementierung
Einmal aktiviert, gibt es kein Zurück: Wenn du kein gültiges SSL-Zertifikat hast oder versehentlich HTTP-Links verwendest, können Besucher deine Seite nicht mehr aufrufen.
8. Subresource Integrity – auch extern geschützt!
💡 Was ist eine Subresource?
Alles, was eine Seite beim Laden nachzieht: Skripte, Stylesheets, Bilder, Schriften… Mit der Policy kannst du sagen, woher die kommen dürfen – und vor allem: woher nicht.
Websites lagern manchmal einen Teil ihrer Inhalte an einen Dritten aus, z. B. ein Content Delivery Network (CDN). So kann beispielsweise eine Webseite, die über https://deine.domain bereitgestellt wird, Inhalte von einem anderen Standort enthalten, z.B. https://dein.cdn.provider/script.js.
Wenn ein Angreifer nun die Kontrolle über den Drittanbieter-Host erlangt, könnte er beliebige bösartige Inhalte einfügen oder die Dateien vollständig ersetzen, und somit auch die belieferten Websites angreifen.
Mit Subresource Integrity kann sichergestellt werden, dass die vom Dritten bezogenen Daten integer – also unverfälscht – sind, und zwar mit einem Hash.
Ich habe auf dieser Website z.B. ein externes Script (Sienna vom MIT) für die Web-Accessibility eingebunden:
<script src="https://website-widgets.pages.dev/dist/sienna.min.js" </>script>Um sicherzustellen, dass meine Websitebesucher nicht Ziel von einem Angriff werden und diese Ressource integer ist, habe ich einen Hash hinzugefügt:
<script src="https://website-widgets.pages.dev/dist/sienna.min.js" integrity="sha384-AghT84hDKeiru8787FlTnerkjh54687FK734usdfgsQPuiqmnyckdf9457jghUDLkdhfe" crossorigin="anonymous"></script>Hashes können mit einem Generator einfach erstellt werden:
⚠️ Achtung! Um SRI verwenden zu können, muss zwingend zusätzlich CORS (s. Pt. 5) verwendet werden.
Praxisbeispiel Sicherheitlücke
Ein CDN wurde kompromittiert, jQuery manipuliert. Nur Seiten mit aktivierter Subresource Integrity blockierten den Angriff – alle anderen führten Schadcode aus.
Mögliche Probleme bei der Implementierung
Externe Skripte (z. B. Google Fonts oder jQuery von CDN) laden nicht, wenn sich die Datei ändert – du musst den Hash regelmäßig aktualisieren.
9. Permission Policy
💡 Was regelt das genau?
Früher hiess die Permission Policy Feature Policy, die Syntax hat teilweise geändert.
Sie bestimmt, ob eingebettete Inhalte (z. B. ein YouTube-Video oder eine Werbeanzeige) Zugriff auf sensible Dinge haben dürfen – wie Kamera, Mikrofon, GPS oder Motion-Sensoren.
Header set Permissions-Policy "geolocation=(), camera=(), microphone=()"
Verhindert, dass deine Seite (oder eingebettete Inhalte!) Kamera & Co. aktivieren. Praktisch, wenn du deine Besucher nicht mit wilden „Darf diese Seite dein Mikro benutzen?“ belästigen möchtest.
⚠️ Achtung! Dieser Header ist noch in der Experimentierphase und wird noch nicht von allen modernern Browsern unterstützt. 👉 Weitere Infos über die Permission Policy.
Praxisbeispiel Sicherheitlücke
Angriffe auf Smartphones, bei denen Websites Zugriff auf die eingebauten Sensoren bekamen, um Bewegungsmuster auszulesen.
Mögliche Probleme bei der Implementierung
Einschränkungen bei Kamera, Mikro, Geolocation etc. können gewünschte Funktionen (Videochat, Maps, Bewegungssensoren) deaktivieren – etwa bei Web-Apps oder VR/AR-Projekten.
10. Cookies – Nur mit Sicherheitsgurt
Wenn du Zugriff auf die Set-Cookie-Header hast (meist über PHP), sollten Cookies mindestens so aussehen:
Header edit Set-Cookie ^(.*)$ "$1; Secure; HttpOnly; SameSite=Strict"So sind sie:
- Nur per HTTPS übertragbar (Secure)
- Nicht via JavaScript auslesbar (HttpOnly)
- Nur bei gleichen Domains gültig (SameSite)
👉 Weitere Infos über die Set-Cookie Policy.
💡 Was ist SameSite?
Cookies können „mitreisen“, wenn du von einer Seite auf eine andere klickst. SameSite verhindert das – oder erlaubt es nur gezielt. Hilft enorm gegen CSRF-Angriffe und Session-Hijacking.
⚠️ Achtung! LiteSpeed Web Server unterstützt die Set-Cookie Richtlinie nicht 👉 LiteSpeed Blogbeitrag. Stattdessen müsste der folgende Code verwendet werden:
<IfModule LiteSpeed>
ForceSecureCookie httponly secure same_site_strict
</IfModule>Praxisbeispiel Sicherheitlücke
CSRF-Angriffe nutzten ungeschützte Cookies, um im Hintergrund Formulare abzusenden – z. B. bei Shopping-Seiten: Adresse ändern → Paket abfangen.
Mögliche Probleme bei der Implementierung
Ältere Browser (z. B. IE11 oder veraltete Safari-Versionen) unterstützen SameSite=None nicht richtig. Auch Drittanbieter-Logins (z. B. Google, Stripe) brauchen teils SameSite=None; Secure. Und LiteSpeed Web Server unterstützt Set-Cookie überhaupt nicht.
11. Content Security Policy – Jetzt wird’s kompliziert
💡 Was ist CSP?
Eine Art „Whitelist“ für Browser: Du sagst ganz genau, was geladen werden darf – und woher. Alles andere wird geblockt.
Perfekt gegen Cross-Site Scripting (XSS). Aber mit Inline-JavaScript (wie bei Divi!) kann das tricky werden.
Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'"Inline-CSS und Inline-Javascript sind die Feinde von CSP. Diese können nur berücksichtigt werden, wenn man die CSP „unsicher“ aufbohrt, und zwar mit „unsafe-inline“ und „data:“. Und dafür bekommt man denn auch vom HTTP Observatory eins an die Löffel.
Viele, viele, viele, viele Dinge gehen nicht mehr mit CSP, weshalb viele – auch grosse – Firmen gar keine CSP für ihre Website implementiert haben.
Für Divi kann man mit „unsafe-inline“ schon einiges erreichen. Allerdings funktioniert dann der Zugriff auf die Divi-Cloud nicht mehr. Hat man noch anderes Scripts, wie die erwähnte „sienna.js“, oder Real Cookie Banner, oder, oder, oder, dann gehören deren (genaue!) URLs auch hier rein. Damit kann man Stunden und Tage verbringen.
👉 Weitere Infos über die Content-Security-Policy
👀 Mein Tipp:
- Erst mit report-only testen
- Nur Stück für Stück verschärfen
- Viel Geduld. Oder halt: Mich buchen.
Praxisbeispiel Sicherheitlücke
Klassischer XSS-Angriff auf eine kommentierbare WordPress-Seite: Nutzer platzierte ein <script> im Kommentar. Ohne CSP wurde es ausgeführt, mit CSP → blockiert.
Mögliche Probleme bei der Implementierung
Divi, Elementor & Co. erzeugen massenhaft Inline-JavaScript und Styles – eine „harte“ CSP bricht da gern mal das Layout oder blockiert legitime Funktionen. Testen ist Pflicht.
12. Fehler identifizieren
Okay, du hast fleißig Security Headers eingebaut – und plötzlich lädt die Google Map nicht mehr, ein schickes Kontaktformular schweigt oder dein schönes Divi-Layout sieht aus wie Tetris auf Speed. Keine Panik!
Hier ein schneller Fahrplan, wie du Fehler sauber aufspürst:
🔍 Schritt 1: Chrome Entwickler-Tools öffnen
- Drücke F12 oder Rechtsklick → Untersuchen auf deiner Seite.
- Wechsle in den Tab „Konsole“ (Console) oder „Netzwerk“ (Network).
Hier siehst du sofort:
- Welche Skripte oder Ressourcen blockiert wurden,
- Welche Header gesetzt wurden (im Reiter „Netzwerk“ → einzelne Datei anklicken → „Header“ anschauen).
Tipp: Achte auf Fehler wie „Refused to load“, „blocked by CSP“, „Mixed Content“ oder ähnliche Hinweise.
🧩 Schritt 2: Fehlermeldungen richtig lesen
Chrome (und andere moderne Browser) sind mittlerweile ziemlich freundlich:
Sie sagen dir ganz genau, welcher Header welche Ressource blockiert – und oft sogar welche Regel in deiner CSP oder anderen Headern schuld ist.
Beispiele:
- Refused to load script because it violates the following Content Security Policy directive: ’script-src …‘
- Blocked loading mixed active content
- Resource interpreted as Stylesheet but transferred with MIME type application/json
🛠️ Schritt 3: Header checken und testen
- Nutze Tools wie securityheaders.com oder observatory.mozilla.org, um zu prüfen, welche Header überhaupt aktiv sind.
- Achte dabei auch auf Schreibfehler (z. B. Content-Security-Policy statt Content-Security_Policy) – Header-Namen sind pingelig.
💡 Profi-Tipp:
Falls du eine neue CSP testest, kannst du erstmal den Modus Content-Security-Policy-Report-Only verwenden. Damit siehst du, was blockiert würde – ohne dass wirklich etwas blockiert wird. Ideal zum gefahrlosen Feintuning!
Content-Security-Policy-Report-Only: default-src https:deine.domain;report-to csp-endpoint="https://deine.domain/csp-reports";13. Zwischen Anspruch und Alltag: Zeit für ein Fazit
Wer das ganz große Kino will, tüftelt wochenlang an seiner Content Security Policy, lässt Reports einlaufen, debuggt CORS-Feinheiten und schlägt sich mit Inline-Skripten herum. Kann man machen.
Aber: Man muss nicht gleich Fort Knox nachbauen, um Einbrechern das Leben schwer zu machen.
Wenn du die „einfachen“ Security Headers umsetzt, bist du schon besser aufgestellt als 95 % der anderen Websites da draußen. Das ist kein Witz – das ist Statistik.
Also:
🔧 Setz die Low-Hanging Headers um
💡 lass die CSP erstmal in der Sandbox spielen
📈 und freu dich über ein solides Sicherheits-Rating
Und wenn du trotzdem das Gefühl hast, das sei alles zu technisch, zu riskant oder einfach nicht dein Thema?
👉 Frage mich an!
Mit Liebe zur Technik, Respekt vor deinem Business – und einem Auge fürs Machbare.
14. Bonus: „Low hanging headers“ zum kopieren
Hier habe ich die – soweit wie möglich – „unkritischen“ Security Headers zusammengefasst. Die kannst Du kopieren und in deine .htaccess-Datei einfügen (mach zuerst eine Kopie deiner .htaccess-Datei!).
Rating vorher:
# HTTPS erzwingen
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
# Security Headers
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains;"
Header set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Access-Control-Allow-Origin "https://deine.domain"
Header set Cross-Origin-Resource-Policy "same-origin"
Header set Permissions-Policy "geolocation=(), camera=(), microphone=()"
Rating nachher:
0 Kommentare