// s-01übernahme
Niemand weiß, was läuft.
Die Website wurde vor Jahren gebaut, die Agentur ist weg, die Dokumentation auch. Niemand kann sagen, welche Erweiterungen installiert sind und wann zuletzt jemand ein Update eingespielt hat.
// audit · security
Security-Audit.
Du willst die Website-Sicherheit prüfen lassen, bevor jemand anders es tut. siteway schaut sich deinen Ist-Zustand an: TLS-Konfiguration, Security-Header wie CSP und HSTS, Cookie-Flags, veraltete Abhängigkeiten und bekannte Lücken (CVEs). Heraus kommt ein security-report — priorisiert, mit Aufwand und nächstem Schritt je Befund.
audit
audit: einzeln buchbar
dauer: 3–5 werktage
output: security-report
// definition
Was ist ein Security-Audit?
Ein Security-Audit prüft den Ist-Zustand deiner Website auf Konfigurations- und Abhängigkeitsebene: TLS, Security-Header, Cookie-Flags, Versionsstände und bekannte Lücken. Es beantwortet zwei Fragen: Was ist an deiner Website offen — und was davon musst du zuerst schließen?
Der Unterschied zu einem kostenlosen Scanner ist nicht die Menge der Prüfpunkte, sondern das Urteil. Ein Tool liefert eine Note von A bis F. Ein Audit sagt dir, welcher der 14 roten Punkte deine Seite wirklich angreifbar macht, welcher nur kosmetisch ist und in welcher Reihenfolge du sie abarbeitest.
Das Audit ist einzeln buchbar. Du bekommst den Report, egal ob wir danach etwas umsetzen oder nicht. Die laufende Absicherung — Updates, Patches, Monitoring — ist eine eigene Leistung: Betrieb, Wartung & Support.
// anlass
Wann sich das Audit lohnt.
bots suchen nicht dich — sie suchen versionen
Angriffe auf normale Business-Websites sind selten persönlich gemeint. Automatisierte Scanner klopfen Adresse für Adresse ab, ob dort eine bekannte Version mit einer bekannten Lücke läuft. Das Audit dreht die Reihenfolge um: Du weißt vorher, was sie finden würden.
// s-02scanner
Ein Tool zeigt Rot.
Ein kostenloser Check hat euch ein F gegeben und eine Liste fehlender Header ausgespuckt. Jetzt liegt sie da — ohne dass jemand sagt, welcher Punkt gefährlich ist und wer ihn anfassen darf.
// s-03nachfrage
Der Kunde fragt nach.
Ein Großkunde, eine Versicherung oder die eigene Compliance will wissen, wie es um die Sicherheit eurer Website steht. Ihr braucht eine belastbare Antwort statt eines Bauchgefühls.
// s-04relaunch
Vor dem Relaunch.
Bevor eine neue Seite auf dieselbe alte Infrastruktur zieht, gehört der Unterbau geprüft. Ein Befundstand vor dem Umzug macht sichtbar, was der Relaunch gleich mit erledigen sollte.
// s-05vorfall
Etwas war schon.
Fremde Weiterleitungen, seltsame Dateien im Webroot, eine Warnung vom Hoster. Nach einem Vorfall muss klar sein, welche Tür offen stand — sonst steht sie nach der Bereinigung wieder offen.
// s-06wechsel
Neuer Hoster, neues Setup.
Nach einem Umzug oder dem Einbau eines CDN kommen Header oft nicht mehr dort an, wo sie sollen. Was auf dem Server konfiguriert ist, muss beim Browser auch ankommen.
// prüfung · 6 bereiche
Was wir prüfen.
jeder bereich ein befund
Sechs Bereiche, defensiv geprüft. Vier davon lesen wir von außen aus — dafür reicht die URL. Für Abhängigkeiten und Versionen brauchen wir Einblick in die Installation, sonst bleibt der Report an der Oberfläche.
// p-01transport
TLS-Konfiguration.
Zertifikat, Zertifikatskette und Laufzeit. Welche Protokollversionen der Server noch annimmt, welche Cipher er anbietet, ob HTTP sauber auf HTTPS weiterleitet und ob gemischte Inhalte die Verschlüsselung unterlaufen.
befund: protokolle · cipher · redirect
// p-02header
Security-Header.
Content-Security-Policy, HSTS, X-Content-Type-Options, frame-ancestors, Referrer-Policy, Permissions-Policy. Und die Frage, die kein Gratis-Tool stellt: Kommen die Header über CDN, Proxy und Server überhaupt konsistent beim Browser an?
befund: csp · hsts · konsistenz
// p-03sessions
Cookies & Sessions.
Tragen Session- und Login-Cookies die Flags Secure, HttpOnly und SameSite? Werden Sessions nach dem Login erneuert, laufen sie ab? Gerade bei Login-Bereichen entscheidet das über die Übernahme fremder Sitzungen.
befund: secure · httponly · samesite
// p-04abhängigkeiten
Abhängigkeiten.
CMS-Core, Erweiterungen, Themes, PHP-Version, Pakete aus Composer und npm. Wir listen auf, was installiert ist, wie alt es ist und was davon noch gepflegt wird — inklusive der Erweiterungen, die niemand mehr benutzt und trotzdem mitlaufen.
befund: versionsstand + altlasten
// p-05cve
Bekannte Lücken.
Die installierten Versionen gleichen wir mit Security-Advisories und CVE-Datenbanken ab. Entscheidend ist nicht die Zahl der Treffer, sondern welche Lücke deine Installation wirklich betrifft — und ob sie überhaupt erreichbar ist.
befund: cve-liste · betroffen ja/nein
// p-06exposition
Exponierte Pfade.
Was liegt öffentlich herum, das dort nicht hingehört: alte Backups, .env- und Konfigurationsdateien, offene Verzeichnislisten, Debug-Ausgaben, ungeschützte Admin-Logins, sprechende Fehlermeldungen mit Pfadangaben.
befund: offene pfade + dateien
// mehrwert
Was der Header-Score nicht sieht.
note ≠ sicherheit
Die Suche nach „Website-Sicherheit prüfen“ führt zu Header-Scannern, die eine Note von A+ bis F vergeben. Die Tools sind gut — und ehrlich. Mozillas HTTP Observatory schreibt selbst in die FAQ, dass es keine veralteten Softwareversionen und keine verwundbaren CMS-Plugins prüft und ein A+ deshalb nicht „sicher“ bedeutet. Genau da beginnt das Audit.
// m-01blindstelle
A+ und trotzdem offen.
Header-Scanner sehen nur die Antwort deines Servers, nicht die Software dahinter. Eine Seite mit perfekten Headern kann auf einer Erweiterung laufen, für die es seit zwei Jahren einen öffentlichen Exploit gibt.
header + abhängigkeiten
// m-02rollout
CSP ohne Scherbenhaufen.
Der häufigste Grund, warum keine Content-Security-Policy gesetzt ist: Beim ersten Versuch war die Seite kaputt. Der Report liefert deshalb keinen Copy-und-Paste-Header, sondern den Weg über Content-Security-Policy-Report-Only — Verstöße sammeln, Policy zuschneiden, dann scharf schalten.
report-only → enforce
// m-03reihenfolge
Reihenfolge statt Liste.
Ein Scanner wirft 30 rote Punkte aus, alle gleich laut. Im Report stehen sie sortiert: was heute gefährlich ist, was diesen Monat drankommt, was warten kann — und je Befund, wer ihn anfassen muss: Hoster, CMS oder Code.
priorität + zuständigkeit
// output
Was du bekommst.
der report gehört dir
Du bekommst den security-report: ein Dokument, das man einem Hoster, einer internen IT oder einer anderen Agentur in die Hand drücken kann, ohne etwas zu erklären. Je Befund steht darin, was gefunden wurde, wo es liegt, was passieren kann, wie aufwendig die Behebung ist und was der nächste Schritt ist.
Befunde sind in vier Stufen sortiert — von kritisch (jetzt) über hoch und mittel bis kosmetisch (kann warten). Dazu je Befund die Zuständigkeit: Server- und Hoster-Sache, CMS-Sache oder Code-Sache. Damit weiß am Ende jeder im Team, was er selbst erledigen kann.
Dazu eine Stunde Durchsprache: Wir gehen den Report gemeinsam durch, du fragst nach, wir sortieren die ersten drei Schritte. Danach entscheidest du frei, wer umsetzt — wir, dein Hoster oder ihr selbst.
// ablauf · 4 schritte
So läuft das Audit.
3–5 werktage bis zum report
-
// schritt 01 · briefing
Umfang klären.
Welche Domains, welches CMS, welches Hosting, gibt es Login-Bereiche oder Schnittstellen. Danach steht der Festpreis.
output: scope + festpreis
-
// schritt 02 · scan
Von außen auslesen.
TLS, Header, Cookies und exponierte Pfade — automatisiert erhoben und anschließend von Hand geprüft, weil Scanner Fehlalarme produzieren.
output: rohbefunde
-
// schritt 03 · abhängigkeiten
Versionen abgleichen.
Mit Lesezugriff auf composer.json, package.json und die Extension-Liste gleichen wir die Versionsstände gegen Advisories und CVE-Datenbanken ab.
output: cve-abgleich
-
// schritt 04 · report ● ergebnis
Report & Durchsprache.
Befunde priorisiert, mit Aufwand, Zuständigkeit und nächstem Schritt. Eine Stunde gemeinsam durchgehen — danach gehört der Report dir.
output: security-report
// faq
Häufige Fragen.
Was ist ein Security-Audit für Websites?
Ein Security-Audit prüft den Ist-Zustand deiner Website auf Konfigurations- und Abhängigkeitsebene: TLS-Konfiguration, Security-Header wie CSP und HSTS, Cookie-Flags, veraltete Versionen von CMS, Erweiterungen und Paketen sowie bekannte Lücken (CVEs). Ergebnis ist ein security-report mit priorisierten Befunden und konkreten nächsten Schritten — nicht nur eine Note von A bis F.
Ist das Audit ein Penetrationstest?
Nein. Wir prüfen Konfiguration, Versionen und Abhängigkeiten und lesen aus, was deine Website nach außen preisgibt. Wir greifen deine Systeme nicht an: kein Ausnutzen von Lücken, keine Brute-Force-Versuche, keine Datenextraktion, kein Social Engineering. Wenn du einen echten Penetrationstest brauchst — etwa für eine Zertifizierung oder eine Kundenanforderung — sagen wir das offen und du beauftragst dafür ein spezialisiertes Pentest-Team. Der security-report ist eine gute Vorarbeit dafür, weil er die offensichtlichen Baustellen vorher wegräumt.
Was kostet das Audit?
Festpreis nach Briefing. Sobald klar ist, wie groß die Installation ist, welches CMS läuft und wie viele Umgebungen dazugehören, nennen wir einen Preis für das Audit und halten ihn fest. Keine Stundenabrechnung, keine Überraschung am Ende.
Müssen wir die Umsetzung bei euch beauftragen?
Nein. Der Report gehört dir. Du kannst ihn deinem Hoster, deiner internen IT oder einer anderen Agentur geben — er ist so geschrieben, dass jemand anders damit arbeiten kann: Befund, Ort, Aufwand, nächster Schritt. Wenn du willst, setzen wir die Befunde um oder übernehmen die laufende Absicherung über Betrieb, Wartung & Support. Musst du aber nicht.
Wie lange dauert das Audit und was braucht ihr von uns?
Für eine normale Business-Website drei bis fünf Werktage. Den Großteil prüfen wir von außen — dafür reicht die URL. Für den Abhängigkeits- und Versionsteil brauchen wir Einblick in die Installation: Lesezugriff auf composer.json, package.json und die Extension- oder Plugin-Liste, alternativ ein Export. Ohne diesen Einblick bleibt der Report an der Oberfläche, und das sagen wir dann auch.
Kann eine Content-Security-Policy unsere Website kaputt machen?
Falsch eingeführt: ja. Eine zu strenge Policy blockiert Skripte, Fonts oder eingebettete Videos, und die Seite sieht plötzlich zerlegt aus. Deshalb steht im Report kein Copy-und-Paste-Header, sondern ein Weg: erst Content-Security-Policy-Report-Only mitlaufen lassen, die gemeldeten Verstöße sammeln, die Policy darauf zuschneiden — und erst dann scharf schalten. So merkt der Besucher vom Umbau nichts.
Wie oft sollten wir die Sicherheit prüfen lassen?
Ein Audit ist eine Momentaufnahme. Header und TLS bleiben stabil, bis jemand die Konfiguration anfasst — Abhängigkeiten altern dagegen jeden Monat weiter. Sinnvoll ist ein Audit vor einem Relaunch, nach einem Hoster- oder Agenturwechsel und danach etwa einmal im Jahr. Wer dauerhaft aktuell bleiben will, braucht kein jährliches Audit, sondern laufende Wartung mit Updates und Patches.
// passt dazu
Passt dazu.
nach dem befund kommt die umsetzung
// leistung · betrieb
Betrieb, Wartung & Support.
Das Audit ist die Momentaufnahme. Updates, Patches, Backups und Monitoring halten den Stand — laufend, nicht einmal im Jahr.
weiterlesen →
// audit · technik
Tech-Audit.
Der technische Zustand jenseits der Sicherheit: Code, Struktur, Rendering und Crawlbarkeit deiner Website.
weiterlesen →
// audit · dns
DNS- & E-Mail-Audit.
SPF, DKIM und DMARC gehören nicht in den security-report, sondern in ein eigenes Audit — damit niemand in deinem Namen mailt.
weiterlesen →
// Wissen, was offen steht?
Audit anfragen