Ihr Programmierer aus Berlin Mitte prüft Ihre Webanwendung
Welche Daten werden verarbeitet? Wo können Nutzer Eingaben machen? Welche Abhängigkeiten und Berechtigungen gibt es? Daraus ergeben sich passende Schutzmaßnahmen.
04 / Sicherheit & Barrierefreiheit
Ihre Webseite soll verlässlich arbeiten und für möglichst viele Menschen nutzbar sein. OHA-Software aus Moabit prüft Schutzmaßnahmen und Zugänglichkeit passend zu den Funktionen, Daten und Nutzern Ihrer Webanwendung.
Prüfung besprechenFünf Fragen, klare Antworten
Wenn Sie Ihre Webseite erneuern oder eine neue Webanwendung programmieren lassen, gehören Sicherheit und Barrierefreiheit in die Planung. Keine Webseite ist hundertprozentig sicher. Schutzmaßnahmen, Updates und regelmäßige Prüfungen reduzieren Risiken; Zugänglichkeit braucht zusätzlich Tests mit unterschiedlichen Bedienweisen.
Es werden möglichst wenige Daten erhoben und nur für den vereinbarten Zweck verarbeitet. Verschlüsselte Übertragung, begrenzte Zugriffsrechte und sichere Serverkonfiguration schützen sensible Informationen.
Zugangsdaten gehören in die Serverumgebung. Technisch notwendige Sitzungs-Cookies erhalten passende Schutzattribute; Aufbewahrung und Löschung werden mit dem Betreiber festgelegt.
Eingaben werden kontrolliert, damit fehlerhafte oder manipulierte Daten keine unerwünschten Folgen verursachen. Hilfreiche Fehler zeigen Nutzern, was sie korrigieren können.
Der Server prüft Typ, Länge, Format und erlaubte Werte. Browserprüfungen verbessern zusätzlich die Bedienung. Spam-Abwehr und eine angemessene Begrenzung von Anfragen ergänzen die Validierung.
Bei sitzungsbasierten Aktionen kann ein CSRF-Token verhindern, dass fremde Websites unbemerkt eine Aktion im Namen des Besuchers auslösen. Die passende Methode richtet sich nach Authentifizierung und Bedrohungsmodell; Spam-Schutz ist eine getrennte Aufgabe.
Eingeschleuste Texte sollen als Text erscheinen und nicht als Programmcode ausgeführt werden. Dafür werden dynamische Ausgaben passend zu ihrem Kontext kodiert.
PHP kann HTML-Texte und geeignete Attribute mit htmlspecialchars() sicher ausgeben. Für JavaScript-, CSS- und URL-Kontexte gelten eigene Regeln. Eingabevalidierung ersetzt diese Ausgabekodierung nicht.
Wenn eine Datenbank erforderlich ist, trennen parametrisierte Abfragen Daten und SQL-Befehle. Dynamische Tabellen- oder Spaltennamen werden nur aus erlaubten Werten gewählt. Eine Datenbank wird nicht allein zur Demonstration hinzugefügt.
Der Server kann dem Browser vorgeben, welche Ressourcen geladen werden dürfen und wie Inhalte behandelt werden. Diese Regeln sind eine zusätzliche Schutzschicht.
Eine Content-Security-Policy begrenzt Quellen, nosniff verhindert unerwünschte Inhaltserkennung und eine Referrer-Policy begrenzt mitgesendete Herkunftsinformationen. HSTS wird erst nach einer vollständigen HTTPS-Prüfung aktiviert.
Cross-Origin-Regeln wie COOP, CORP, COEP und CORS haben unterschiedliche Aufgaben. Sie werden nach Bedarf gewählt und auf Verträglichkeit geprüft. Wir sprechen erst von wirksamen Hostingregeln, wenn ihre tatsächliche Auslieferung getestet wurde.
Eine Website soll auch mit Tastatur, Screenreader und Vergrößerung gut nutzbar sein. Klare Überschriften, ausreichende Kontraste, sichtbarer Fokus und beschriftete Formulare helfen dabei.
Wir orientieren uns an WCAG 2.2 AA, verwenden bevorzugt native HTML-Elemente und prüfen schmale Ansichten sowie reduzierte Bewegung. Informative Bilder bekommen passende Alternativtexte, dekorative Bilder keine unnötigen Beschreibungen.
Automatische Tests finden viele Fehler, belegen aber keine vollständige Konformität. Tastatur- und Screenreadertests sowie die Prüfung der tatsächlichen Inhalte gehören zur Abnahme.
Die Ergebnisse einer Prüfung sollen verständlich und umsetzbar sein.
Welche Daten werden verarbeitet? Wo können Nutzer Eingaben machen? Welche Abhängigkeiten und Berechtigungen gibt es? Daraus ergeben sich passende Schutzmaßnahmen.
Navigation, Formulare und Inhalte werden mit Tastatur, Vergrößerung und unterstützenden Techniken geprüft. Konkrete Probleme werden nach Wirkung und Aufwand priorisiert.
Webseite erneuern und Schutzmaßnahmen verbessern
Fachliche Orientierung: WCAG 2.2 beim W3C und die OWASP Cheat Sheet Series.
Der nächste Schritt
Beschreiben Sie Ihre Ausgangslage. Gemeinsam klären wir, welcher Weg zu Ihrem Projekt passt.