Ihr Code im Visier: Warum TypeScript-Sicherheit keine Option, sondern eine Notwendigkeit ist
\n\nHaben Sie sich jemals gefragt, was passiert, wenn ein Benutzer in das Suchfeld Ihrer Website nicht einfach „Python-Bücher“ eingibt, sondern etwas wie '; DROP TABLE users; --? Wenn Ihr Backend in TypeScript nicht auf eine solche Wendung vorbereitet ist, riskieren Sie nicht nur einen Fehler, sondern den Verlust Ihrer gesamten Datenbank. Klingt wie ein Horrorszenario? Willkommen in der realen Welt der Webentwicklung, in der TypeScript-Sicherheit kein modisches Feature, sondern grundlegende Code-Hygiene ist.
In diesem Artikel halten wir keine langweiligen Vorträge. Wir analysieren die beiden Hauptfeinde jeder Webanwendung: SQL-Injection und XSS (Cross-Site-Scripting). Sie erfahren, wie Hacker Ihre Projekte angreifen, und vor allem, wie Sie Ihren TypeScript-Code mit realen Beispielen und Best Practices in eine uneinnehmbare Festung verwandeln.
\n\nSQL-Injection: Wie Angreifer mit Ihrer Datenbank „sprechen“
\n\nStellen Sie sich vor, Ihre Anwendung ist ein höflicher Concierge, der jede Bitte eines Gastes erfüllt. Wenn der Gast fragt: „Zeigen Sie mir Raum Nr. 5“, zeigt der Concierge ihn. Aber was, wenn der Gast fragt: „Zeigen Sie mir alle Räume und geben Sie mir die Schlüssel zum Safe“? Ohne Überprüfung würde der Concierge auch das tun. SQL-Injection funktioniert genauso: Der Angreifer „bettet“ seine Befehle in eine normale Benutzereingabe ein.
\n\nAngenommen, Sie haben eine einfache Abfrage, um einen Benutzer nach Namen zu suchen:
\n\n// ❌ GEFÄHRLICH: anfälliger Code\nconst userName = req.body.username; // Benutzer hat "admin" eingegeben\nconst query = `SELECT * FROM users WHERE name = '${userName}'`;\ndb.execute(query);\n\nSieht harmlos aus? Stellen Sie sich nun vor, der Benutzer gibt ein: admin' OR '1'='1. Die Abfrage wird zu:
SELECT * FROM users WHERE name = 'admin' OR '1'='1'\n\nHerzlichen Glückwunsch! Sie haben dem Angreifer soeben die Liste aller Benutzer des Systems übergeben. Und wenn er etwas löschen möchte? Einfach: admin'; DROP TABLE users; -- – und Ihre Datenbank ist weg.
Wie man sich schützt: Parametrisierte Abfragen – Ihr Schild
\n\nDie Hauptregel für den Schutz vor SQL-Injection in TypeScript: Fügen Sie Benutzerdaten niemals direkt in die Abfragezeichenfolge ein. Verwenden Sie parametrisierte Abfragen (vorbereitete Anweisungen). Sie trennen SQL-Code und Daten, und die Datenbank behandelt die Benutzereingabe ausschließlich als Daten, nicht als Befehle.
\n\nBeispiel mit der Bibliothek pg (für PostgreSQL):
// ✅ SICHER: parametrisierte Abfrage\nimport { Pool } from 'pg';\n\nconst pool = new Pool({\n connectionString: process.env.DATABASE_URL\n});\n\nasync function getUserByName(userName: string): Promise<any> {\n const query = 'SELECT * FROM users WHERE name = $1';\n const result = await pool.query(query, [userName]);\n return result.rows;\n}\n\n// Verwendung\nconst userInput = req.body.username; // selbst wenn es "admin' OR '1'='1" ist\nconst user = await getUserByName(userInput);\n// Die Datenbank behandelt dies als Suche nach einem Benutzer mit diesem seltsamen Namen\nconsole.log(user); // [] – nichts gefunden\n\nDas gleiche Prinzip gilt auch für andere ORMs wie Prisma oder TypeORM. Sie verwenden standardmäßig parametrisierte Abfragen, was die TypeScript-Sicherheit zu einer integrierten Funktion macht.
\n\n// ✅ SICHER: Verwendung von Prisma\nimport { PrismaClient } from '@prisma/client';\n\nconst prisma = new PrismaClient();\n\nasync function findUser(name: string) {\n return prisma.user.findUnique({\n where: { name: name } // Prisma escaped die Eingabedaten selbst\n });\n}\n\nXSS-Angriffe: Wenn Ihre Website fremden Code ausstrahlt
\n\nWenn SQL-Injection die Datenbank trifft, dann greift XSS (Cross-Site-Scripting) Ihre Benutzer an. Stellen Sie sich vor, ein Angreifer