Wie verteidigst du eine Webanwendung gegen XSS, CSRF und SQL Injection?

Alle drei entstehen dadurch, dass nicht vertrauenswürdige Eingaben in einen vertrauenswürdigen Kontext gemischt werden. Stopp SQL Injection mit parametrisierten Queries, niemals mit String-Verkettung. Stopp XSS mit kontextabhängigem Output-Encoding, indem du rohe HTML-Injektion meidest, jedes HTML sanitizest, das du rendern musst, und eine strikte Content Security Policy setzt. Stopp CSRF mit SameSite-Cookies plus einem Token pro Session auf zustandsändernden Requests, oder mit einem eigenen Header, den ein fremdes Formular nicht setzen kann.

Ich denke an sie als eine Form: Daten von einem Nutzer landen irgendwo, wo sie interpretiert werden. Bei SQL ist der Interpreter die Datenbank, parametrisierte Queries oder ein Query Builder, der Werte bindet, lösen es also vollständig, und es gibt keinen akzeptablen Grund, einen String zu verketten. Bei XSS ist der Interpreter der Browser, und der springende Punkt ist, dass Escaping kontextabhängig ist. React escaped Textknoten für mich, das Risiko konzentriert sich also in den Notausgängen: rohe HTML-Injektion, href-Werte, die eine javascript-URL sein könnten, und alles, was direkt ins DOM geschrieben wird. Wo ein Produkt wirklich Nutzer-HTML braucht, etwa ein Rich-Text-Feld, sanitize ich serverseitig mit einer Allowlist-Bibliothek und ergänze eine strikte CSP als zweite Schicht, damit ein Durchrutscher nicht automatisch eine Kontoübernahme ist. CSRF greift nur, wenn der Browser Credentials automatisch anhängt, SameSite auf Lax killt also das meiste davon, und ich ergänze trotzdem ein Token pro Session auf allem, was Zustand ändert. Cookies bekommen selbstverständlich httpOnly und Secure.