WebForensik
Ergebnisse für https://www.mba-worldwide.com/
Analysezeitpunkt: 2026-11-04 21:07:02
Gesamtbewertung
Score-Verlauf für diese Domain Kompletten Verlauf ansehen →
✔ Diese Website erfüllt grundlegende Datenschutzanforderungen.
Hinweis: Diese automatisierte Analyse ersetzt keine rechtliche Beratung. Für eine vollständige DSGVO-Bewertung konsultieren Sie einen Datenschutzbeauftragten.
↓ Detaillierte Ergebnisse zu allen Kategorien finden Sie weiter unten.
Die Website nutzt eine verschlüsselte Verbindung (HTTPS).
Neueste Verschlüsselung aktiv (TLS 1.3 — TLSv1.3).
Das Sicherheitszertifikat ist gültig (läuft ab am 2026-12-24).
Ausreichende Verschlüsselungsmethode (TLS_AES_128_GCM_SHA256, 128 Bit).
HSTS ist aktiviert — der Browser wird angewiesen, immer die verschlüsselte Verbindung zu nutzen.
HSTS-Dauer: 31536000 Sekunden (mindestens 1 Jahr) — sehr gut.
HSTS gilt auch für alle Subdomains (includeSubDomains).
Content Security Policy vorhanden (via Meta-Tag).
Inline-Skripte erlaubt (unsafe-inline). Schwächt den XSS-Schutz für inline-Code; die anderen CSP-Direktiven schützen weiter.⚠ Bei Einsatz von WORDPRESS unumgänglich durch Vorgaben von Wordpress selbst.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung
Ihre CSP erlaubt „unsafe-inline" für Skripte — damit hebeln Sie den XSS-Schutz weitgehend aus. Lösung: Inline-Skripte mit einer „Nonce" oder einem Hash signieren, statt sie pauschal zu erlauben. Das ist technisch anspruchsvoller — eine Aufgabe für den Webentwickler.
WordPress Spezial für WordPress: so tragen Sie es ein
WordPress-Plugin: WordPress-Themes haben oft Inline-Skripte, die durch wp_localize_script() oder Plugin-Output entstehen. Pragmatischer Zwischenschritt: „unsafe-inline" vorerst belassen, dafür Inline-Skripte schrittweise nach extern auslagern (eigene .js-Dateien). Profi-Lösung: Plugin „WP Content Security Policy & Headers" mit Nonce-Support.
✓ So prüfen Sie, ob es funktioniert: Wenn Nonce-basierte CSP aktiv: F12 → Konsole — keine Meldung „Refused to execute inline script because it violates …" mehr.
Gute Grundregel: Nur eigene Inhalte sind standardmäßig erlaubt (default-src: self).
Referrer-Policy: strict-origin-when-cross-origin (via Meta-Tag).
Sichere Einstellung „strict-origin-when-cross-origin" — kein Pfad-Leak, kein HTTP-Downgrade-Leak. Bestmöglich.
MIME-Typ-Schutz aktiv (nosniff) — Browser interpretieren Dateien nicht falsch.
Clickjacking-Schutz aktiv: X-Frame-Options = SAMEORIGIN.
Permissions-Policy ist konfiguriert — Zugriff auf sensible Geräte-APIs wird kontrolliert.
5 von 6 sensiblen APIs eingeschränkt — sehr gut.
Keine Cookies gesetzt — vorbildlich für den Datenschutz.
Kein lokaler Speicher (Web Storage) genutzt — kein Tracking-Risiko.
31 Anfrage(n) an 5 verschiedene Drittanbieter-Server.
5 Drittanbieter-Server innerhalb der EU/des EWR.
Aufgerufene URLs:
https://zityad.com/biz_css/mba/js/jquery-3.7.1.min.js
https://zityad.com/biz_css/mba/js/aos.css
https://zityad.com/biz_css/mba/js/swiper-bundle.min.css
https://zityad.com/biz_css/mba/tailwind.css?v=2
https://zityad.com/biz_css/mba/forms.css
https://zityad.com/biz_css/mba/mila-wall.css
https://zityad.com/biz_css/mba/template.css
https://zityad.com/biz_css/mba/fonts/IBMPlexSansVar-latin.woff2
https://zityad.com/biz_css/mba/fonts/IBMPlexSansVar-latin-ext.woff2
https://zityad.com/biz_css/mba/js/aos.js
https://zityad.com/biz_css/mba/mila-wall.js
https://zityad.com/biz_css/mba/js/cdn.min.js
https://zityad.com/biz_css/tailwing/app_js.js
Aufgerufene URLs:
https://account.bcs.tools/ai-assistant/style.css
https://account.bcs.tools/form-widget/app.js
https://account.bcs.tools/ai-assistant/app.js
https://account.bcs.tools/form-widget/app.css
https://account.bcs.tools/api/v1/public/forms/2432
https://account.bcs.tools/api/v1/adscampaigns/visit
https://account.bcs.tools/api/v1/public/forms/2433
... und 1 weitere Anfrage(n)
Aufgerufene URLs:
https://www.zityad.com/ccm19/ccm19/public/app.js?apiKey=8aa763fa14fcb3b4660d389a3bccaa492da3a607b94f0f04&domain=1ec1059
https://www.zityad.com/ccm19/ccm19/public/app.css?apiKey=8aa763fa14fcb3b4660d389a3bccaa492da3a607b94f0f04&domain=1ec1059&gen=2&theme=faaea5e&v=1793809772
https://www.zityad.com/ccm19/ccm19/public/widget?apiKey=8aa763fa14fcb3b4660d389a3bccaa492da3a607b94f0f04&domain=1ec1059&gen=2&theme=faaea5e&lang=de_DE&v=1793809772
https://www.zityad.com/ccm19/ccm19/public/widget/details?apiKey=8aa763fa14fcb3b4660d389a3bccaa492da3a607b94f0f04&domain=1ec1059&gen=2&theme=faaea5e&lang=de_DE&v=1793809772
https://www.zityad.com/ccm19/ccm19/public/statistics/consent?apiKey=8aa763fa14fcb3b4660d389a3bccaa492da3a607b94f0f04&domain=1ec1059&gen=2&theme=faaea5e
... und 1 weitere Anfrage(n)
Aufgerufene URLs:
https://crm.biz24.online/form-widget/app.js
https://crm.biz24.online/api/v1/adscampaigns/hit?Url=https%3A%2F%2Fwww.mba-worldwide.com%2F&PageId=24032528&ProductId=null&AdsCampaignId=null&username=null
... und 1 weitere Anfrage(n)
Aufgerufene URLs:
https://biz24.online/image/1047512/cookietool.png
Keine bekannten Tracker erkannt.
0 von 20 externen Ressource(n) nutzen Integritätsprüfung (SRI).
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung
Nur ein Teil Ihrer externen Ressourcen (0 von 20) ist mit SRI gesichert. Ergänzen Sie integrity-Attribute auch bei den restlichen.
WordPress Spezial für WordPress: so tragen Sie es ein
WordPress-Plugin: Vorgehen: Quelltext der Seite ansehen → alle <script src="https://…"> und <link href="https://…"> ohne integrity-Attribut → unter https://www.srihash.org/ Hash erzeugen → integrity="sha384-…" crossorigin="anonymous" ergänzen. Plugin „WP-SRI" kann das für viele Fälle automatisieren.
✓ So prüfen Sie, ob es funktioniert: F12 → Konsole bei Seitenladung: keine „Failed to find a valid digest"-Meldungen. Quelltext: alle externen <script>/<link> haben integrity-Attribut.
Keine externen Ressourcen nutzen Integritätsprüfung. Manipulierte Dateien würden nicht erkannt.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung
SRI (Subresource Integrity) ist eine Prüfsumme, die im HTML-Code angibt, wie eine extern geladene Datei aussehen MUSS. Manipuliert jemand die externe Datei (z.B. wenn ein CDN gehackt wird), lädt der Browser sie nicht aus. Sie ergänzen das Attribut „integrity" am script/link-Tag.
WordPress Spezial für WordPress: so tragen Sie es ein
WordPress-Plugin: In WordPress lassen sich SRI-Hashes selten manuell ergänzen (Skripte werden via wp_enqueue_script() gesetzt). Plugin „WP-SRI" (im Plugin-Verzeichnis) ergänzt integrity-Hashes automatisch für externe Skripte/Styles. Für statisch ins Theme eingebundene Ressourcen: Hash unter https://www.srihash.org/ generieren, integrity="sha384-…" und crossorigin="anonymous" am <script>/<link>-Tag ergänzen.
✓ So prüfen Sie, ob es funktioniert: F12 → Netzwerk → Anfragen mit Code 200 von CDN-Domains (cdn.jsdelivr.net, cdnjs.cloudflare.com etc.) → im HTML-Quelltext muss der Tag „integrity=\"sha384-…\" crossorigin=\"anonymous\"" enthalten.
Keine CAA-Einträge. Jede Zertifizierungsstelle könnte ein Zertifikat für diese Domain ausstellen.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung
CAA-Einträge (Certification Authority Authorization) legen im DNS fest, welche Zertifizierungsstellen Zertifikate für Ihre Domain ausstellen dürfen. Ohne CAA-Eintrag könnte ein Angreifer bei jeder beliebigen CA ein falsches Zertifikat für Ihre Domain bestellen. Der Eintrag ist eine reine DNS-Konfiguration und wird im DNS-Panel Ihres Domain-Anbieters (NICHT in WordPress) gesetzt.
☞ Konkrete CAA-Werte für die zehn häufigsten Hoster (DACH-Raum)
Suchen Sie Ihren Hoster in der Tabelle, kopieren Sie die passenden Werte ins DNS-Panel. Bei Mehrfach-CAs: für jede CA einen eigenen CAA-Record anlegen (alle mit Tag issue, Flag 0, Name @). Zusätzlich empfohlen: ein iodef-Record mit einer Kontakt-E-Mail für Missbrauchs-Meldungen.
| # | Hoster | Verwendete CA(s) | CAA-Wert(e) — Tag issue |
|---|---|---|---|
| 1 | Hetzner Webhosting (Basic-Zertifikat, kostenlos im Paket) | DigiCert (Programm „Encryption Everywhere") | digicert.com |
| 1 | Hetzner Webhosting (Let’s Encrypt, kostenlos) | Let’s Encrypt (ISRG) | letsencrypt.org |
| 2 | All-Inkl | Let’s Encrypt + Sectigo (Pro) | letsencrypt.orgsectigo.com |
| 3 | IONOS (1&1) | DigiCert (GeoTrust) + Let’s Encrypt | digicert.comletsencrypt.org |
| 4 | STRATO | Sectigo + Let’s Encrypt | sectigo.comletsencrypt.org |
| 5 | Cloudflare (Universal SSL) | Google Trust Services + DigiCert + Let’s Encrypt | pki.googdigicert.comletsencrypt.org |
| 6 | AWS (ACM / CloudFront) | Amazon Trust Services | amazon.comamazontrust.comawstrust.comamazonaws.com |
| 7 | Mittwald | Let’s Encrypt + Sectigo | letsencrypt.orgsectigo.com |
| 8 | Webgo | Let’s Encrypt + Sectigo | letsencrypt.orgsectigo.com |
| 9 | raidboxes (Managed WordPress) | Let’s Encrypt | letsencrypt.org |
| 10 | Host Europe / DomainFactory | Sectigo + Let’s Encrypt | sectigo.comletsencrypt.org |
Name Typ Flag Tag Wert
@ CAA 0 issue "digicert.com"
@ CAA 0 issue "letsencrypt.org"
@ CAA 0 iodef "mailto:security@ihre-domain.de"Die iodef-Zeile (letzte Zeile) ist optional aber empfohlen: dort melden CAs Missbrauchsversuche an Sie. Falls Sie eine Sub-Domain zusätzlich absichern wollen (z.B. shop.ihre-domain.de), separate Records mit dem Sub-Domain-Namen statt @ anlegen — moderne CAs prüfen aber auch parent-CAA automatisch.
Wenn Sie Ihren Hoster nicht in der Liste finden: Schauen Sie das aktuell ausgestellte Zertifikat im Browser an (Schloss-Symbol → Zertifikat anzeigen → Aussteller). Dort steht der CA-Name (z.B. „Sectigo RSA Domain Validation Secure Server CA" → Wert sectigo.com). Den Wert als CAA-Record anlegen, fertig.
WordPress Spezial für WordPress: so tragen Sie es ein
WordPress-Plugin: Die CAA-Records werden NICHT in WordPress angelegt, sondern im DNS-Panel Ihres Domain-Anbieters oder DNS-Providers (z.B. Hetzner-Robot, IONOS-Domains, Cloudflare-Dashboard, INWX, ns3.hajo-nolte.de etc.). Übliche Bezeichnung im DNS-Panel: „CAA-Record" oder unter „TXT-Records" mit Typ-Auswahl „CAA". Je CA ein separater Record.
✓ So prüfen Sie, ob es funktioniert: Auf https://www.ssllabs.com/ssltest/analyze.html?d=ihre-domain.de → Abschnitt „DNS CAA" → alle Ihre CAs sollten dort aufgelistet sein. Oder per dig: dig CAA ihre-domain.de.
Keine IPv6-Unterstützung (kein AAAA-Eintrag).
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung
Ihre Domain hat keine IPv6-Adresse (AAAA-Eintrag). Über 40% aller deutschen Internetnutzer sind über IPv6 unterwegs (Mobilfunk vor allem) — die müssen dann den Umweg über IPv4-Gateways nehmen, was langsamer ist.
WordPress Spezial für WordPress: so tragen Sie es ein
WordPress-Plugin: Reine DNS+Server-Sache. Schritt 1: prüfen, ob Ihr Hoster eine IPv6-Adresse für Sie hat (im Kundenpanel oder per Support-Anfrage). Schritt 2: im DNS-Panel einen AAAA-Eintrag mit dieser IPv6 anlegen. Schritt 3: testen.
✓ So prüfen Sie, ob es funktioniert: dig AAAA ihre-domain.de — oder online https://ipv6-test.com/validate.php?url=ihre-domain.de.
Kein SPF-Eintrag. E-Mails können im Namen dieser Domain gefälscht werden.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung
SPF (Sender Policy Framework) legt im DNS fest, welche Server E-Mails im Namen Ihrer Domain versenden dürfen. Ohne SPF kann jeder Phisher E-Mails so aussehen lassen, als kämen sie von Ihnen — und Empfänger werden eher reinfallen.
WordPress Spezial für WordPress: so tragen Sie es ein
WordPress-Plugin: DNS-Sache, nicht WordPress. Im DNS-Panel einen TXT-Eintrag anlegen. Beispiele: Wenn Sie KEINE E-Mails versenden: v=spf1 -all (alle Versender ablehnen). Wenn nur Ihr Hoster versendet (z.B. All-Inkl): v=spf1 a mx ~all. Wenn Google Workspace: v=spf1 include:_spf.google.com ~all. Wenn Microsoft 365: v=spf1 include:spf.protection.outlook.com -all.
✓ So prüfen Sie, ob es funktioniert: dig TXT ihre-domain.de | grep spf — oder online https://www.kitterman.com/spf/validate.html.
Kein DMARC-Eintrag. Die Domain ist anfällig für E-Mail-Phishing.
▸ So beheben Sie das — Schritt-für-Schritt-Anleitung
DMARC kombiniert SPF und DKIM zu einer expliziten Anweisung an empfangende Mail-Server: „Was tun, wenn E-Mails behaupten von uns zu kommen, aber SPF/DKIM scheitert?" Ohne DMARC entscheidet jeder Mail-Server selbst — meist großzügig. Mit DMARC=reject verhindern Sie wirksam Phishing in Ihrem Namen.
WordPress Spezial für WordPress: so tragen Sie es ein
WordPress-Plugin: DNS-Sache. TXT-Eintrag bei Subdomain _dmarc.ihre-domain.de. Empfohlene Stufen: Beobachten erst: v=DMARC1; p=none; rua=mailto:dmarc-reports@ihre-domain.de — mehrere Wochen Berichte ansehen. Dann verschärfen: v=DMARC1; p=quarantine; rua=… — verdächtige Mails landen im Spam. Final: v=DMARC1; p=reject; rua=… — werden ganz abgewiesen.
✓ So prüfen Sie, ob es funktioniert: dig TXT _dmarc.ihre-domain.de — oder online https://dmarcian.com/dmarc-inspector/.
security.txt gefunden: https://www.mba-worldwide.com/.well-known/security.txt
Kontaktfeld vorhanden (Pflichtfeld) — Sicherheitsforscher können Schwachstellen melden.
Ablaufdatum vorhanden (Pflichtfeld).
Bevorzugte Sprachen angegeben.
Keine externen Reporting-Endpunkte erkannt.
Kein Consent-Banner nötig — keine Tracker oder Drittanbieter-Cookies erkannt.
Datenschutzerklärung verlinkt: „https://www.mba-worldwide.com/datenschutz" (https://www.mba-worldwide.com/datenschutz).
Impressum verlinkt: „Impressum" (https://www.mba-worldwide.com/impressum).
Datenschutzerklärung ist erreichbar (HTTP 200).
⚙ Ihre fertige Security-htaccess
Alle fehlenden Security-Header zu einem einzigen Block kombiniert. Diesen Block ans Ende Ihrer .htaccess hängen — fertig. 1 Header werden gesetzt.
⚠ Warum diese Empfehlung KEINEN 100%-Score gibt — und warum das mit WordPress so ist
Die Content-Security-Policy oben enthält bewusst 'unsafe-inline' sowohl für style-src als auch für script-src. Damit ist KEIN vollständiger XSS-Schutz möglich — das ist eine pragmatische Entscheidung, kein Bug.
Warum? Ein typisches WordPress-Setup (Theme + 5-15 Plugins) schreibt 10-50 verschiedene Inline-<script>-Blocks ins HTML: jQuery-Init, Slider-Initialisierung, Cookie-Banner, Tracking, GTM, Web Vitals, Lazy-Load, Speculation Rules usw. Wenn die strikte CSP script-src 'self' diese alle blockt, ist die Site optisch und funktional kaputt (Slider weiß, Cookie-Banner zerschossen, Plugins tot). Genau dieses Problem hatten Sie soeben mit Ihrer Slider-Seite.
Konsequenz fürs Scoring: Sites, die WordPress mit Plugins einsetzen, können in dieser App maximal ~75-85 Punkte in der CSP-Kategorie erreichen — das volle 100%-Rating ist erst möglich, wenn der inline-Code per Nonce oder Hash signiert wird (technisch anspruchsvoll, bricht bei jedem Theme/Plugin-Update).
Wege zum vollen XSS-Schutz (in steigender Komplexität):
- Plugin „WP Content Security Policy & Headers" — fügt automatisch Nonces zu inline-Scripts hinzu (mittlerer Aufwand, sauberste WP-Lösung).
- Hash-basierte CSP — jedes inline-Script per SHA-256 in der CSP whitelisten (fragil, bricht bei Updates).
- Inline-Scripts externalisieren — Theme/Plugins so umbauen, dass kein inline-JS mehr ausgegeben wird (großer Aufwand, oft unmöglich).
Wer keinen dieser Wege geht, lebt mit 'unsafe-inline' — wie ca. 95% aller produktiven WordPress-Sites im Web. Die anderen CSP-Direktiven schützen weiterhin: default-src 'self' blockt externe Ressourcen, object-src 'none' verbietet Flash/Java, frame-ancestors 'self' verhindert Clickjacking, base-uri 'self' verhindert Base-Tag-Hijacking. Es ist kein Maximalschutz, aber realistischer Schutz für die WP-Praxis.
Apache Standard-Apache (für alle Hoster, ohne WordPress)
Diesen Block ans Ende Ihrer .htaccess im Web-Root hängen — fertig.
<IfModule mod_headers.c>
Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; font-src 'self' https: data:; object-src 'none'; frame-ancestors 'self'; base-uri 'self'; upgrade-insecure-requests"
</IfModule>WordPress WordPress: .htaccess im WP-Root
Diesen Block OBERHALB der Zeile „# BEGIN WordPress" einfügen, sonst überschreibt WP ihn bei Permalink-Änderungen.
# BEGIN WebForensik Security
<IfModule mod_headers.c>
Header always set Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; font-src 'self' https: data:; object-src 'none'; frame-ancestors 'self'; base-uri 'self'; upgrade-insecure-requests"
</IfModule>
# END WebForensik SecurityWordPress Alternative für WordPress: functions.php im Child-Theme
Falls Ihr Hoster .htaccess-Änderungen nicht erlaubt: dieses PHP-Snippet ans Ende der functions.php Ihres CHILD-Themes hängen. Vorher Backup machen — NIE das Haupt-Theme bearbeiten, das wird bei Updates überschrieben.
add_action('send_headers', function () {
header("Content-Security-Policy: default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; font-src 'self' https: data:; object-src 'none'; frame-ancestors 'self'; base-uri 'self'; upgrade-insecure-requests");
});| Header | Wert |
|---|---|
| access-control-allow-methods | GET,POST,PUT,DELETE,OPTIONS |
| access-control-allow-origin | * |
| alt-svc | h3=":443"; ma=2592000 |
| cache-control | no-cache |
| content-encoding | gzip |
| content-length | 32113 |
| content-type | text/html; charset=UTF-8 |
| date | Wed, 04 Nov 2026 20:06:56 GMT |
| permissions-policy | camera=(), microphone=(), geolocation=(), payment=(), usb=() |
| server | Caddy Apache/2.4.25 (Debian) |
| strict-transport-security | max-age=31536000; includeSubDomains |
| vary | Accept-Encoding |
| x-content-type-options | nosniff |
| x-frame-options | SAMEORIGIN |
Bewertung auf Ihrer Website einbetten
Zeigen Sie Ihren WebForensik-Score öffentlich. Das Badge ist ein leichtes SVG, lädt schnell und respektiert die Privatsphäre Ihrer Besucher (kein Tracking).
HTML-Code zum Einbetten (dieser konkrete Scan)
<a href="https://webforensik.de/results.php?id=4087" target="_blank" rel="noopener">
<img src="https://webforensik.de/badge.php?id=4087" alt="WebForensik Score" width="174" height="28">
</a>Oder dynamisch — zeigt immer den jüngsten Scan dieser Domain
<a href="https://webforensik.de/?url=https://mba-worldwide.com" target="_blank" rel="noopener">
<img src="https://webforensik.de/badge.php?domain=mba-worldwide.com" alt="WebForensik Score" width="174" height="28">
</a>