Die OWASP Top 10 erscheint alle paar Jahre — und jedes Mal verschiebt sich der Schwerpunkt. Die 2026-Liste ist keine reine Aktualisierung bekannter Risiken, sondern eine Verschiebung dessen, was die Community als „kritisch“ einstuft. In diesem Artikel gehen wir die drei wichtigsten Änderungen durch und zeigen, wie unser Bot-Ökosystem darauf reagiert.

Was sich 2026 geändert hat

Die 2026-Liste verschiebt mehrere Risiken nach oben, die in der Bot-/Plattform-Welt besonders relevant sind: fehlerhafte Konfiguration von Drittanbieter-Integrationen, unsichere Standard-Einstellungen in produktiven Deployments, und übermäßiges Vertrauen in clientseitige Validierung. Wir hatten Glück, dass zwei dieser drei Risiken schon vor der Veröffentlichung in unserem Threat-Model auftauchten — der dritte Punkt war eine echte Überraschung.

OWASP-2026 ist weniger eine neue Bedrohungslandschaft als eine ehrlichere Einschätzung der bestehenden. Die meisten Punkte sind altbekannt — neu ist nur, dass wir uns nicht mehr hinter „selten ausgenutzt“ verstecken können.

A01: Fehlerhafte Drittanbieter-Konfiguration

Discord-Webhooks, OAuth-Provider, Sentry-DSNs, Log-Aggregatoren — unser Bot-Stack integriert eine ganze Reihe von Drittanbietern. Jeder davon braucht eine eigene Konfiguration, und ein einziger falsch gesetzter Token-Typ („public“ statt „restricted“ zum Beispiel) kann die gesamte Integrität kippen.

Unsere Antwort ist eine zentrale Integrations-Konfigurationsdatei mit strikter Typ-Validierung beim Boot. Wir lehnen Konfigurationen ab, die gegen unsere Mindeststandards verstoßen, und loggen den Abbruch mit einem klaren Hint, was zu tun ist:

// integrations.config.ts — wird beim Boot geladen
import { z } from "zod";

const WebhookConfigSchema = z.object({
  url: z.string().url().refine((u) => u.startsWith("https://"), {
    message: "Webhook URL muss https sein",
  }),
  type: z.enum(["public", "restricted", "internal"]),
  // 'public' ist nur für nicht-privilegierte Embeds erlaubt
  // 'restricted' erfordert zusätzlich eine Scope-Validierung
  // 'internal' ist nur in service-to-service-Topologien
});

export const integrations = WebhookConfigSchema.parse(rawConfig);

Der Vorteil: Wenn jemand versehentlich einen Webhook auf `http://` setzt oder den falschen Token-Typ wählt, schlägt der Bot beim Start fehl — nicht erst zur Laufzeit, wenn bereits Schaden entstanden ist.

A02: Unsichere Standard-Einstellungen

Default-Konfigurationen sind ein zweischneidiges Schwert. Sie sollen den Einstieg erleichtern, dürfen aber nie die Sicherheit schwächen. Die 2026-OWASP-Liste betont, dass zu viele produktive Deployments mit Default-Werten laufen, die für die Entwicklungsumgebung gedacht waren — etwa deaktivierte Rate-Limits oder weitreichende CORS-Policies.

Bei uns ist jede Integration in drei Profile getrennt: development, staging, production. Die Profile sind explizit, nicht implizit — du musst `NODE_ENV=production` setzen, damit das production-Profil greift, und das production-Profil hat grundsätzlich restriktivere Defaults:

• Rate-Limits sind in production 4× strenger als in development
• CORS ist in production auf die eigene Domain beschränkt
• Debug-Logging ist in production standardmäßig deaktiviert
• Stack-Traces in API-Responses sind in production abgeschaltet

Diese Defaults stehen in einer zentralen `env-profiles.ts` und werden beim Boot mit `assertProductionSafety()` gegen die aktuelle Konfiguration geprüft. Wenn jemand versehentlich `NODE_ENV=development` in production setzt, schlägt der Bot beim Start fehl.

A03: Übermäßiges Vertrauen in clientseitige Validierung

Das war die Überraschung der 2026-Liste. Wir hatten angenommen, dass Bot-Operatoren ohnehin wissen, dass clientseitige Validierung wertlos ist. Aber: Slash-Command-Optionen in Discord sind de facto eine clientseitige Eingabe. Wir haben in der Vergangenheit die Werte aus Slash-Commands direkt in unsere Datenbank geschrieben, mit nur minimaler Server-seitiger Validierung.

Das ist ein Problem, weil Discord-Clients (auch der offizielle) theoretisch beliebige Werte an Slash-Command-Endpoints senden können. Unsere Audit-Stichprobe hat ergeben, dass etwa 12 % unserer Command-Handler Lücken hatten, wo clientseitig validierte Werte direkt persistiert wurden.

Die Antwort war ein konzernweiter Audit. Wir haben einen `validateCommandInput()`-Helper geschrieben, der als Pflicht-Pre-Commit-Hook läuft und jede Command-Option gegen ein Zod-Schema validiert. Commands, die diesen Helper nicht nutzen, schlagen in CI fehl.

Beispiel: vorher vs. nachher

// VORHER — direkter Zugriff auf den rohen Command-Wert
const reason = interaction.options.getString("reason");
await db.moderationCases.create({ reason });

// NACHHER — validierter Wert mit striktem Schema
const schema = z.string().min(3).max(500);
const reason = schema.parse(interaction.options.getString("reason"));
await db.moderationCases.create({ reason });

Der Unterschied sieht klein aus, aber der zweite Block lehnt leere Strings, Strings über 500 Zeichen und Nicht-String-Werte ab, bevor sie die Datenbank erreichen.

Audit-Checks, die wir aufgesetzt haben

Aus den drei Risiken haben wir vier konkrete Audit-Checks abgeleitet, die jetzt in CI laufen:

• Integrations-Schema-Check: Jede Integrations-Konfiguration muss das zentrale Zod-Schema erfüllen
• Production-Defaults-Check: production-Profile werden gegen die strengen Defaults geprüft
• Command-Validation-Check: Jeder Command-Handler muss `validateCommandInput()` nutzen
• Token-Type-Check: Alle Secrets werden auf ihren Typ geprüft (z.B. „restricted token in public context" ist ein Hard-Fail)

Diese Checks laufen in CI und blockieren Merges, die gegen eines der Risiken verstoßen. Die Checks sind absichtlich laut — nicht nur ein Warning im Log, sondern ein CI-Failure mit klarer Anleitung, was zu tun ist.

Was wir nicht gemacht haben

Wir haben bewusst keine automatisierte Bedrohungsmodellierung eingeführt. Die OWASP-2026-Liste ist wertvoll, aber sie ist eine Awareness-Liste, kein Action-Plan. Stattdessen konzentrieren wir uns auf die vier Checks, die in CI laufen, und auf manuelle Reviews bei Architektur-Änderungen. Das ist weniger, aber messbar wirksam.

Erkenntnisse für andere Teams

Drei Punkte, die wir aus dem Audit mitnehmen:

• Defaults sind Sicherheit. Wenn du Default-Werte für production festlegst, mach sie restriktiv. „Bequem" ist ein Anti-Pattern in production.
• Clientseitige Validierung ist keine Validierung. Auch nicht, wenn der Client „offiziell" aussieht.
• Audit-Checks gehören in CI, nicht ins Wiki. Ein Check, der nur dokumentiert ist, wird ignoriert.

Die OWASP-2026-Liste ist ein guter Anlass, die eigenen Defaults und Validierungen zu hinterfragen. Wir haben den Audit in einem Sprint durchgezogen — eine Woche Aufwand, ein dauerhaft besseres Sicherheitsfundament.