Sie haben eine Firewall. Sie verwenden HTTPS. Sie führen „npm audit“ aus. Aber wenn ich die JSON-Nutzlast einer „Kauf“-Anfrage so ändern kann, dass sie „Preis: 0,01“ sendet und Ihr Server dies akzeptiert, ist Ihre Firewall nutzlos.

Penetrationstests (Pentesting) ist die Disziplin des Adversarial Engineering. Es geht nicht darum, „Kästchen“ zur Einhaltung der Vorschriften anzukreuzen. Es geht darum, aktiv zu versuchen, die eigene Anwendung zu zerstören, bevor es jemand anderes tut.

Bei Maison Code Paris betrachten wir Sicherheit als die ultimative Form der Qualitätssicherung. Ärgerlich ist ein Bug, der die App zum Absturz bringt. Ein Fehler, der 10.000 Kreditkarten von Kunden preisgibt, ist existenziell.

Warum Maison Code darüber spricht

Bei Maison Code Paris fungieren wir als das architektonische Gewissen unserer Kunden. Wir übernehmen oft „moderne“ Stacks, die ohne grundlegendes Verständnis für Skalierung gebaut wurden.

Wir diskutieren dieses Thema, weil es einen kritischen Wendepunkt in der technischen Reife darstellt. Die korrekte Implementierung unterscheidet ein fragiles MVP von einer widerstandsfähigen Plattform auf Unternehmensniveau.

Die Grenzen der Automatisierung

Die meisten Teams betreiben einen automatisierten Scanner (wie OWASP ZAP oder Nessus) und denken, dass sie sicher sind. Scanner eignen sich hervorragend zum Auffinden von Syntaxfehlern:

SQL-Injection („OR 1=1“).
XSS (<script>alert(1)</script>).
Veraltete Bibliotheken (CVE-2023-XXXX).

Scanner sind schlecht darin, Logikfehler zu finden:

„Kann ich denselben Rabattcode 50 Mal gleichzeitig anwenden?“
„Kann ich den Bestellverlauf von Benutzer-ID 5 einsehen, wenn ich als Benutzer-ID 4 angemeldet bin?“
„Kann ich den Preis des Artikels negativ setzen?“

Hierbei handelt es sich um Sicherheitslücken in der Geschäftslogik, die den Großteil der finanziellen Verluste im modernen E-Commerce ausmachen.

Sicherheitslücke 1: IDOR (Unsichere direkte Objektreferenz)

Dies ist der häufigste Fehler in modernen APIs (GraphQL/REST). Dies geschieht, wenn Sie darauf vertrauen, dass der Client Ihnen sagt, auf welche Ressource Sie zugreifen sollen, ohne die Eigentümerschaft zu überprüfen.

Der Angriff: Benutzer A meldet sich an. Er schaut sich die URL oder die Registerkarte „Netzwerk“ an: GET /api/orders/5001 Sie ändern es in: GET /api/orders/5002

Wenn der Server die Bestellung von Benutzer B zurückgibt, haben Sie ein IDOR.

Der anfällige Code: „Typoskript // SCHLECHT: Der vom Benutzer bereitgestellten ID wird vertraut app.get(‘/api/orders/:id’, async (req, res) => { const order = waiting db.order.findUnique({ wobei: { id: req.params.id } }); res.json(order); }); „

Der Sicherheitscode: „Typoskript // GUT: Beschränkung der Abfrage auf den authentifizierten Benutzer app.get(‘/api/orders/:id’, async (req, res) => { const session = waiting getSession(req); const order = waiting db.order.findFirst({ wo: { id: req.params.id, userId: session.userId // Die kritische Prüfung } });

if (!order) return res.status(404).send(“Not Found”); // Sagen Sie nicht „Verboten“, sondern einfach „Nicht gefunden“, um Lecks zu vermeiden res.json(order); }); „

Sicherheitslücke 2: Rennbedingungen (Der Coupon-Hack)

Webserver sind gleichzeitig. Sie bearbeiten Tausende von Anfragen pro Sekunde. Wenn Ihre Datenbanklogik nicht „Thread-sicher“ (oder transaktionssicher) ist, sind Sie anfällig.

Der Angriff:

Die Website sendet einen Promo-Code: „SAVE50“ (maximal 1 Nutzung pro Kunde).
Der Angreifer schreibt ein Skript, um 50 HTTP-POST-Anfragen gleichzeitig an „/apply-coupon“ zu senden (innerhalb von 5 ms).
Der Server verarbeitet Anfrage 1: „Benutzer hat Gutschein verwendet? Nein. Rabatt anwenden.“
Der Server verarbeitet Anfrage 2 (bevor Anfrage 1 an DB übermittelt wird): „Benutzer hat Gutschein verwendet? Nein. Rabatt anwenden.“
Ergebnis: Der Benutzer erhält den 50-fachen Rabatt. Die Bestellung ist kostenlos.

Die Lösung: Datenbanksperre: Sie müssen Transaktionen mit der richtigen Isolationsstufe oder expliziter Zeilensperre verwenden.

„sql — PostgreSQL / MySQL ANFANG; SELECT * FROM users WHERE id = 1 FOR UPDATE; – Sperrt die Zeile

Überprüfen Sie die Gutscheinverwendung
Gutschein einlösen UPDATE-Benutzer SET Coupon_used = true WHERE id = 1; BEGEHEN; „

Verwenden Sie in Prisma/ORM-Begriffen „€transaction“ wenn möglich mit interaktiver Isolation oder verwenden Sie einen Mutex in Redis, wenn Sie mit verteilten Zählern arbeiten.

Sicherheitslücke 3: Angriffe auf die Lieferkette

Im Jahr 2025 schreiben Sie 10 % Ihres Codes. Die anderen 90 % stammen von „node_modules“. Hacker haben aufgehört, Ihren Server anzugreifen. Sie greifen Ihre Abhängigkeiten an. Sie veröffentlichen ein Paket wie „lodash-utils“ (Tippfehler) oder kompromittieren das Konto eines beliebten Paketbetreuers.

Tiefenverteidigung:

Sperrdateien: Immer „package-lock.json“ festschreiben. Es sorgt für exakte Versionen.
CI-Audits: Führen Sie „npm audit —audit-level=high“ in Ihrer Build-Pipeline aus. Der Build schlägt fehl, wenn kritische Punkte gefunden werden.
Moderne Tools: Verwenden Sie Socket.dev oder Snyk. Sie analysieren das Verhalten des Pakets („Warum benötigt diese CSS-Bibliothek Netzwerkzugriff?“).

Sicherheitslücke 4: NoSQL-Injection

Jeder kennt SQL-Injection. Aber wenn Sie MongoDB verwenden, sind Sie nicht immun. MongoDB erlaubt Abfrageobjekte. Wenn Sie rohes JSON vom Client akzeptieren: „db.users.find({ username: req.body.username })“.

Der Angriff: Der Benutzer sendet JSON: { "username": { "€gt": "" } }. Dies bedeutet: „Finden Sie Benutzer, bei denen der Benutzername größer als eine leere Zeichenfolge ist.“ Das passt zu jedem. Der Angreifer meldet sich als erster Admin-Benutzer an.

Die Lösung: Eingaben desinfizieren. Übergeben Sie „req.body“ niemals direkt an eine Datenbankabfrage. Verwenden Sie Bibliotheken wie „zod“, um die Struktur zu validieren (stellen Sie sicher, dass „Benutzername“ eine Zeichenfolge und kein Objekt ist).

„Typoskript import { z } from ‘zod’;

const LoginSchema = z.object({ Benutzername: z.string(), // Lehnt Objekte wie { €gt: "" } ab Passwort: z.string() });

const body = LoginSchema.parse(req.body); // Wird ausgelöst, wenn ungültig „

Die Rote-Team-Übung

Bei Maison Code empfehlen wir eine vierteljährliche Red Team-Übung. Wir benennen zwei Ingenieure, die die Staging-Umgebung angreifen dürfen.

Sie versuchen, die Zahlung zu umgehen.
Sie versuchen, Privilegien auszuweiten.
Sie versuchen, auf die Daten anderer Benutzer zuzugreifen.

Diese „Gamifizierung“ der Sicherheit schafft eine Kultur, in der Entwickler stolz darauf sind, Lücken zu finden, anstatt sich zu schämen.

10. Bug-Bounty-Programme (Hacker als Angestellte)

Sie können nicht genügend Sicherheitsingenieure einstellen. Aber Sie können die Hacker der Welt mieten. Wir unterstützen Kunden beim Start auf HackerOne oder Bugcrowd.

Richtlinie: „Wenn Sie einen P1 (kritisch) finden, zahlen wir 5.000 €.“
Ergebnis: Innerhalb von 24 Stunden werden 500 Forscher Ihre Website untersuchen. Sie werden Dinge finden, die Ihr 100.000-Dollar-Scanner übersehen hat. „Ich habe einen Weg gefunden, 2FA zu umgehen, indem ich den ‚Token‘-Parameter entfernt habe.“ Für diese Feststellung 5.000 US-Dollar zu zahlen, ist günstiger als eine DSGVO-Strafe in Höhe von 5 Millionen US-Dollar.

Ihre Firewall ist stark. Ihre Rezeptionistin ist nett. Hacker wissen das. Phishing-Simulation: Wir versenden gefälschte E-Mails an Ihre Mitarbeiter. „Dringend: CEO braucht Überweisung.“ Wenn sie klicken, werden sie für die Schulung angemeldet. Physische Sicherheit: Kann ich Ihr Büro effektiv betreten? Sicherheit besteht nicht nur aus Code; es sind Menschen.

12. Cloud Security Posture Management (CSPM)

Sie haben den Code gesichert. Aber haben Sie den S3-Eimer offen gelassen? CSPM-Tools (Wiz, Orca) scannen Ihre AWS-Umgebung. „Warnung: RDS-Datenbank-Port 5432 ist für 0.0.0.0/0 geöffnet.“ Dies ist kein Codefehler. Es ist ein Konfigurationsfehler. Wir betrachten Infrastructure as Code (Terraform) als Sicherheitsgrenze. „checkov“ wird in unserer CI-Pipeline ausgeführt, um jeden Commit zu blockieren, der eine Sicherheitsgruppe für die Welt öffnet.

13. Geheimes Scannen (Das Git-History-Problem)

Sie haben im Jahr 2021 versehentlich „AWS_SECRET_KEY“ festgeschrieben. Sie haben es beim nächsten Commit gelöscht. Es befindet sich immer noch in der „.git“-Historie. Hacker klonen Ihr Repo und sehen sich das Protokoll an. Wir verwenden TruffleHog oder GitGuardian, um den gesamten Commit-Verlauf zu scannen. Wenn ein Geheimnis gefunden wird, rotieren wir es sofort. Der Widerruf des Schlüssels ist die einzige Lösung.

14. Fazit

Sicherheit ist kein Produkt, das Sie kaufen. Es ist eine Denkweise. Wenn Sie denken: „Ich bin zu klein, um gehackt zu werden“, liegen Sie falsch. Bots scannen ständig jede IP-Adresse im Internet. Es ist ihnen egal, ob Sie ein Fortune-500-Unternehmen oder ein Blog sind. Wenn Sie eine Sicherheitslücke haben, wird diese zum Schürfen von Kryptowährungen oder zum Versenden von Spam ausgenutzt.

Behandeln Sie Ihre Bewerbung wie eine Festung. Überprüfen Sie jedes Tor. Vertraue niemandem.

Ist Ihr Schloss sicher?

Warten Sie nicht auf eine Lücke.

Stellen Sie unsere Sicherheitsarchitekten ein für ein umfassendes Code-Audit und einen Penetrationstest. Beauftragen Sie unsere Architekten.