Sicherheit von TypeScript-Anwendungen: Top-10-Schwachstellen für Einsteiger

Sicherheit von TypeScript-Anwendungen: Top-10-Schwachstellen für Einsteiger

TypeScript ist eine Erweiterung von JavaScript, die statische Typisierung hinzufügt, aber nicht vor klassischen Webschwachstellen schützt. Anfänger verlassen sich oft auf die Strenge der Typen und vergessen dabei die Sicherheit auf Logik- und Datenebene. In diesem Artikel analysieren wir die 10 häufigsten Schwachstellen in TypeScript-Anwendungen mit Codebeispielen und Schutzmethoden.

1. XSS (Cross-Site Scripting) durch dangerouslySetInnerHTML

Eines der häufigsten Probleme ist das Einfügen von Benutzer-HTML ohne Bereinigung. In TypeScript tritt dies oft bei der Arbeit mit React oder Angular auf.

// ❌ Angreifbarer Code\nfunction UserComment({ comment }: { comment: string }) {\n  return <div dangerouslySetInnerHTML={{ __html: comment }} />;\n}\n\n// ✅ Sichere Variante\nimport DOMPurify from 'dompurify';\n\nfunction SafeComment({ comment }: { comment: string }) {\n  const sanitized = DOMPurify.sanitize(comment);\n  return <div dangerouslySetInnerHTML={{ __html: sanitized }} />;\n}

2. SQL-Injection durch String-Abfragen

TypeScript schützt nicht vor SQL-Injection, wenn Sie rohe Strings verwenden. Verwenden Sie immer parametrisierte Abfragen.

// ❌ Gefährlich\nconst query = `SELECT * FROM users WHERE email = '${userEmail}'`;\n\n// ✅ Sicher (Beispiel mit Prisma)\nconst user = await prisma.user.findUnique({\n  where: { email: userEmail }\n});

3. Unsichere Speicherung von Geheimnissen im Code

API-Schlüssel, Tokens und Passwörter sollten nicht in den Quellcode gelangen. TypeScript wird in JavaScript kompiliert, und alle Zeichenfolgen bleiben lesbar.

// ❌ Tun Sie das niemals\nconst API_KEY = 'sk-1234567890abcdef';\n\n// ✅ Verwenden Sie Umgebungsvariablen\nconst API_KEY = process.env.API_KEY;\nif (!API_KEY) throw new Error('API_KEY fehlt');

4. NoSQL-Injection (MongoDB)

Bei der Arbeit mit MongoDB über Mongoose oder den Treiber kann versehentlich ein Abfrageobjekt übergeben werden, das die Logik manipuliert.

// ❌ Angreifbarer Code\napp.post('/login', async (req, res) => {\n  const user = await User.findOne({ \n    email: req.body.email, \n    password: req.body.password \n  });\n});\n\n// ✅ Sichere Variante\napp.post('/login', async (req: Request, res: Response) => {\n  const { email, password } = req.body;\n  if (typeof email !== 'string' || typeof password !== 'string') {\n    return res.status(400).send('Ungültige Eingabe');\n  }\n  const user = await User.findOne({ email, password });\n});

5. CSRF (Cross-Site Request Forgery)

Wenn Ihre Anwendung Cookie-Authentifizierung verwendet, kann ein Angreifer Aktionen im Namen des Benutzers ausführen.

// ❌ Fehlender Schutz\napp.post('/transfer', (req, res) => {\n  // Ausführung der Überweisung ohne Quellprüfung\n});\n\n// ✅ Schutz durch CSRF-Token (Beispiel mit csurf)\nimport csrf from 'csurf';\nconst csrfProtection = csrf({ cookie: true });\napp.post('/transfer', csrfProtection, (req, res) => {\n  // Sichere Ausführung\n});

6. Prototype Pollution (Verschmutzung von Prototypen)

Beim Zusammenführen von Objekten ohne Prüfung können Prototyp-Eigenschaften überschrieben werden, was zu Schwachstellen führt.

// ❌ Gefährlich\nfunction merge(target: any, source: any) {\n  for (const key in source) {\n    target[key] = source[key];\n  }\n}\n\n// ✅ Sicher\nfunction safeMerge(target: Record<string, any>, source: Record<string, any>) {\n  for (const key in source) {\n    if (Object.prototype.hasOwnProperty.call(source, key)) {\n      target[key] = source[key];\n    }\n  }\n}

7. Informationsleck durch Fehler

Stack-Traces und Datenbankdetails sollten dem Benutzer nicht angezeigt werden. TypeScript kann aufgrund strenger Typen die Wachsamkeit einschläfern.

// ❌ Schlecht\napp.use((err, req, res, next) => {\n  res.status(500).json({ error: err.m