Fähigkeit: Sicherheitsprüfung
Diese Fähigkeit stellt sicher, dass der gesamte Code den besten Sicherheitspraktiken entspricht und potenzielle Schwachstellen identifiziert.
Wann zu aktivieren
- Implementierung von Authentifizierung oder Autorisierung
- Verarbeitung von Benutzereingaben oder Dateiuploads
- Erstellung neuer API-Endpunkte
- Arbeit mit Geheimnissen oder Anmeldeinformationen
- Implementierung von Zahlungsfunktionen
- Speichern oder Übertragen sensibler Daten
- Integration von Drittanbieter-APIs
Sicherheitscheckliste
1. Geheimnisverwaltung
FEHLER: NIEMALS so tun
const apiKey = "sk-proj-xxxxx" // Hartcodiertes Geheimnis
const dbPassword = "password123" // Im Quellcode
ERFOLG: IMMER so tun
const apiKey = process.env.OPENAI_API_KEY
const dbUrl = process.env.DATABASE_URL
// Überprüfen, ob Geheimnisse vorhanden sind
if (!apiKey) {
throw new Error('OPENAI_API_KEY nicht konfiguriert')
}
Überprüfungsschritte
- Keine hartcodierten API-Schlüssel, Tokens oder Passwörter
- Alle Geheimnisse in Umgebungsvariablen
-
.env.localin .gitignore - Keine Geheimnisse im Git-Verlauf
- Produktionsgeheimnisse in der Hosting-Plattform (Vercel, Railway)
2. Eingabevalidierung
Benutzereingaben immer validieren
import { z } from 'zod'
// Validierungsschema definieren
const CreateUserSchema = z.object({
email: z.string().email(),
name: z.string().min(1).max(100),
age: z.number().int().min(0).max(150)
})
// Vor der Verarbeitung validieren
export async function createUser(input: unknown) {
try {
const validated = CreateUserSchema.parse(input)
return await db.users.create(validated)
} catch (error) {
if (error instanceof z.ZodError) {
return { success: false, errors: error.issues }
}
throw error
}
}
Datei-Upload-Validierung
function validateFileUpload(file: File) {
// Größenprüfung (max. 5 MB)
const maxSize = 5 * 1024 * 1024
if (file.size > maxSize) {
throw new Error('Datei zu groß (max. 5 MB)')
}
// Typenprüfung
const allowedTypes = ['image/jpeg', 'image/png', 'image/gif']
if (!allowedTypes.includes(file.type)) {
throw new Error('Ungültiger Dateityp')
}
// Erweiterungsprüfung
const allowedExtensions = ['.jpg', '.jpeg', '.png', '.gif']
const extension = file.name.toLowerCase().match(/\.[^.]+$/)?.[0]
if (!extension || !allowedExtensions.includes(extension)) {
throw new Error('Ungültige Dateierweiterung')
}
return true
}
Überprüfungsschritte
- Alle Benutzereingaben mit Schemata validiert
- Datei-Uploads eingeschränkt (Größe, Typ, Erweiterung)
- Keine direkte Verwendung von Benutzereingaben in Abfragen
- Whitelist-Validierung (nicht Blacklist)
- Fehlermeldungen geben keine sensiblen Informationen preis
3. SQL-Injection-Prävention
FEHLER: NIEMALS SQL verketten
// GEFÄHRLICH - SQL-Injection-Schwachstelle
const query = `SELECT * FROM users WHERE email = '${userEmail}'`
await db.query(query)
ERFOLG: IMMER parametrisierte Abfragen verwenden
// Sicher - parametrisierte Abfrage
const { data } = await supabase
.from('users')
.select('*')
.eq('email', userEmail)
// Oder mit rohem SQL
await db.query(
'SELECT * FROM users WHERE email = $1',
[userEmail]
)
Überprüfungsschritte
- Alle Datenbankabfragen verwenden parametrisierte Abfragen
- Keine Zeichenfolgenverkettung in SQL
- ORM/Abfrage-Builder korrekt verwendet
- Supabase-Abfragen ordnungsgemäß bereinigt
4. Authentifizierung & Autorisierung
JWT-Token-Handhabung
// FEHLER: FALSCH: localStorage (anfällig für XSS)
localStorage.setItem('token', token)
// ERFOLG: RICHTIG: httpOnly-Cookies
res.setHeader('Set-Cookie',
`token=${token}; HttpOnly; Secure; SameSite=Strict; Max-Age=3600`)
Autorisierungsprüfungen
export async function deleteUser(userId: string, requesterId: string) {
// IMMER zuerst die Autorisierung überprüfen
const requester = await db.users.findUnique({
where: { id: requesterId }
})
if (requester.role !== 'admin') {
return NextResponse.json(
{ error: 'Nicht autorisiert' },
{ status: 403 }
)
}
// Mit Löschung fortfahren
await db.users.delete({ where: { id: userId } })
}
Row-Level-Sicherheit (Supabase)
-- RLS auf allen Tabellen aktivieren
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
-- Benutzer können nur ihre eigenen Daten anzeigen
CREATE POLICY "Benutzer sehen eigene Daten"
ON users FOR SELECT
USING (auth.uid() = id);
-- Benutzer können nur ihre eigenen Daten aktualisieren
CREATE POLICY "Benutzer aktualisieren eigene Daten"
ON users FOR UPDATE
USING (auth.uid() = id);
Überprüfungsschritte
- Tokens in httpOnly-Cookies gespeichert (nicht localStorage)
- Autorisierungsprüfungen vor sensiblen Operationen
- Row-Level-Sicherheit in Supabase aktiviert
- Rollenbasierte Zugriffskontrolle implementiert
- Sitzungsverwaltung sicher
5. XSS-Prävention
HTML bereinigen
import DOMPurify from 'isomorphic-dompurify'
// IMMER vom Benutzer bereitgestelltes HTML bereinigen
function renderUserContent(html: string) {
const clean = DOMPurify.sanitize(html, {
ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'p'],
ALLOWED_ATTR: []
})
return <div dangerouslySetInnerHTML={{ __html: clean }} />
}
Content-Security-Policy
Streng beginnen und nur mit einem dokumentierten Entfernungsplan lockern. Standardmäßig nicht auf
'unsafe-inline' oder 'unsafe-eval' setzen; sie neutralisieren einen Großteil des CSP-Schutzes
und sollten als vorübergehende Kompatibilitätsschuld behandelt werden.
// next.config.js
const securityHeaders = [
{
key: 'Content-Security-Policy',
value: `
default-src 'self';
base-uri 'self';
object-src 'none';
frame-ancestors 'none';
script-src 'self';
style-src 'self';
img-src 'self' data: https:;
font-src 'self';
connect-src 'self' https://api.example.com;
`.replace(/\s{2,}/g, ' ').trim()
}
]
Überprüfungsschritte
- Vom Benutzer bereitgestelltes HTML bereinigt
- CSP-Header konfiguriert
- Keine unvalidierte dynamische Inhaltsdarstellung
- Reaktions eingebauter XSS-Schutz verwendet
6. CSRF-Schutz
CSRF-Tokens
import { csrf } from '@/lib/csrf'
export async function POST(request: Request) {
const token = request.headers.get('X-CSRF-Token')
if (!csrf.verify(token)) {
return NextResponse.json(
{ error: 'Ungültiges CSRF-Token' },
{ status: 403 }
)
}
// Anfrage verarbeiten
}
SameSite-Cookies
res.setHeader('Set-Cookie',
`session=${sessionId}; HttpOnly; Secure; SameSite=Strict`)
Überprüfungsschritte
- CSRF-Tokens bei zustandsändernden Operationen
- SameSite=Strict bei allen Cookies
- Double-Submit-Cookie-Muster implementiert
7. Ratenbegrenzung
API-Ratenbegrenzung
import rateLimit from 'express-rate-limit'
const limiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 Minuten
max: 100, // 100 Anfragen pro Fenster
message: 'Zu viele Anfragen'
})
// Auf Routen anwenden
app.use('/api/', limiter)
Teure Operationen
// Aggressive Ratenbegrenzung für Suchen
const searchLimiter = rateLimit({
windowMs: 60 * 1000, // 1 Minute
max: 10, // 10 Anfragen pro Minute
message: 'Zu viele Suchanfragen'
})
app.use('/api/search', searchLimiter)
Überprüfungsschritte
- Ratenbegrenzung auf allen API-Endpunkten
- Strengere Grenzwerte für teure Operationen
- IP-basierte Ratenbegrenzung
- Benutzerbasierte Ratenbegrenzung (authentifiziert)
8. Offenlegung sensibler Daten
Protokollierung
// FEHLER: FALSCH: Protokollierung sensibler Daten
console.log('Benutzeranmeldung:', { email, password })
console.log('Zahlung:', { cardNumber, cvv })
// ERFOLG: RICHTIG: Sensible Daten schwärzen
console.log('Benutzeranmeldung:', { email, userId })
console.log('Zahlung:', { last4: card.last4, userId })
Fehlermeldungen
// FEHLER: FALSCH: Interne Details offenlegen
catch (error) {
return NextResponse.json(
{ error: error.message, stack: error.stack },
{ status: 500 }
)
}
// ERFOLG: RICHTIG: Generische Fehlermeldungen
catch (error) {
console.error('Interner Fehler:', error)
return NextResponse.json(
{ error: 'Ein Fehler ist aufgetreten. Bitte versuchen Sie es erneut.' },
{ status: 500 }
)
}
Überprüfungsschritte
- Keine Passwörter, Tokens oder Geheimnisse in Protokollen
- Fehlermeldungen für Benutzer generisch
- Detaillierte Fehler nur in Serverprotokollen
- Keine Stack-Traces, die Benutzern angezeigt werden
9. Blockchain-Sicherheit (Solana)
Wallet-Verifizierung
import { verify } from '@solana/web3.js'
async function verifyWalletOwnership(
publicKey: string,
signature: string,
message: string
) {
try {
const isValid = verify(
Buffer.from(message),
Buffer.from(signature, 'base64'),
Buffer.from(publicKey, 'base64')
)
return isValid
} catch (error) {
return false
}
}
Transaktionsverifizierung
async function verifyTransaction(transaction: Transaction) {
// Empfänger überprüfen
if (transaction.to !== expectedRecipient) {
throw new Error('Ungültiger Empfänger')
}
// Betrag überprüfen
if (transaction.amount > maxAmount) {
throw new Error('Betrag überschreitet Grenzwert')
}
// Überprüfen, ob der Benutzer über ausreichend Guthaben verfügt
const balance = await getBalance(transaction.from)
if (balance < transaction.amount) {
throw new Error('Nicht genügend Guthaben')
}
return true
}
Überprüfungsschritte
- Wallet-Signaturen verifiziert
- Transaktionsdetails validiert
- Guthabenprüfungen vor Transaktionen
- Kein blindes Transaktionssignieren
10. Abhängigkeitssicherheit
Regelmäßige Updates
# Auf Schwachstellen prüfen
npm audit
# Automatisch behebbare Probleme beheben
npm audit fix
# Abhängigkeiten aktualisieren
npm update
# Nach veralteten Paketen suchen
npm outdated
Sperrdateien
# IMMER Sperrdateien committen
git add package-lock.json
# In CI/CD für reproduzierbare Builds verwenden
npm ci # Statt npm install
Überprüfungsschritte
- Abhängigkeiten aktuell
- Keine bekannten Schwachstellen (npm audit clean)
- Sperrdateien committed
- Dependabot auf GitHub aktiviert
- Regelmäßige Sicherheitsupdates
Sicherheitstests
Automatisierte Sicherheitstests
// Authentifizierung testen
test('erfordert Authentifizierung', async () => {
const response = await fetch('/api/protected')
expect(response.status).toBe(401)
})
// Autorisierung testen
test('erfordert Admin-Rolle', async () => {
const response = await fetch('/api/admin', {
headers: { Authorization: `Bearer ${userToken}` }
})
expect(response.status).toBe(403)
})
// Eingabevalidierung testen
test('lehnt ungültige Eingabe ab', async () => {
const response = await fetch('/api/users', {
method: 'POST',
body: JSON.stringify({ email: 'not-an-email' })
})
expect(response.status).toBe(400)
})
// Ratenbegrenzung testen
test('erzwingt Ratenbegrenzung', async () => {
const requests = Array(101).fill(null).map(() =>
fetch('/api/endpoint')
)
const responses = await Promise.all(requests)
const tooManyRequests = responses.filter(r => r.status === 429)
expect(tooManyRequests.length).toBeGreaterThan(0)
})
Pre-Deployment-Sicherheitscheckliste
Vor JEDER Produktionsbereitstellung:
- Geheimnisse: Keine hartcodierten Geheimnisse, alle in Umgebungsvariablen
- Eingabevalidierung: Alle Benutzereingaben validiert
- SQL-Injection: Alle Abfragen parametrisiert
- XSS: Benutzerinhalte bereinigt
- CSRF: Schutz aktiviert
- Authentifizierung: Korrekte Token-Handhabung
- Autorisierung: Rollenprüfungen vorhanden
- Ratenbegrenzung: Auf allen Endpunkten aktiviert
- HTTPS: In der Produktion erzwungen
- Sicherheitsheader: CSP, X-Frame-Options konfiguriert
- Fehlerbehandlung: Keine sensiblen Daten in Fehlern
- Protokollierung: Keine sensiblen Daten protokolliert
- Abhängigkeiten: Aktuell, keine Schwachstellen
- Row-Level-Sicherheit: In Supabase aktiviert
- CORS: Korrekt konfiguriert
- Datei-Uploads: Validieret (Größe, Typ)
- Wallet-Signaturen: Verifiziert (falls Blockchain)
Ressourcen
Denken Sie daran: Sicherheit ist optional. Eine Schwachstelle kann die gesamte Plattform gefährden. Im Zweifelsfall lieber auf Nummer sicher gehen.