Essenziali di sicurezza: rate limit, header CSP, cifratura di chiavi, audit pre-pubblici di repo

Panoramica

Nell'istante in cui la tua app e su Internet, e sondata da bot in pochi minuti. Non hai bisogno di una squadra di sicurezza per essere sicuro contro gli attacchi comuni, hai bisogno di un pugno di essenziali, applicati sistematicamente: limita ogni endpoint pubblico con un rate limit, blocca con una CSP cio che il browser eseguira, cifra le credential che memorizzi, logga chi ha fatto cosa, e non passare mai un repo in pubblico senza auditare la sua cronologia per i segreti. Questa lezione rende ciascuno concreto.

Cosa imparerai

Imparerai ad aggiungere rate limit agli endpoint pubblici, a porre un header Content Security Policy, a cifrare le credential memorizzate a riposo, a tenere un audit log utile e a far girare un audit pre-pubblico di repo che coglie i segreti nascosti in vecchi commit. Sono le misure che separano un progetto hobbistico da qualcosa su cui puoi responsabilmente dirigere veri utenti.

Prerequisiti

Le lezioni sui segreti dei Corsi 1 e 3, perche piu misure qui si appoggiano sul tenere i segreti nelle variabili d'ambiente e fuori dal codice. Un'app in deploy con almeno un endpoint o form pubblico rende la lezione concreta, ma puoi applicare tutto al tuo prossimo progetto dal primo commit.

Il problema

Tre omissioni nuocciono ai piccoli builder ancora e ancora. Primo: un endpoint non protetto si fa martellare - un form di login brute-forcato, un form di contatto spammato o un endpoint di IA chiamato in loop finche la tua fattura fornitore esplode. Secondo: una chiave API o una password memorizzata siede in chiaro, cosicche una sola fuga di database da a un attaccante tutto in una volta. Terzo, e il piu frequente: un fondatore rende un repo pubblico per condividerlo, e un segreto committato due anni fa e ora per sempre su Internet aperto. Ognuno e evitabile con un'abitudine.

Rate-limita ogni endpoint pubblico

Un rate limit limita quante volte un solo client puo toccare un endpoint in una finestra di tempo. E il controllo di sicurezza meno caro e al piu alto rendimento che hai, e ogni endpoint che uno sconosciuto puo raggiungere ne ha bisogno di uno: login, signup, reset di password, form di contatto e soprattutto ogni endpoint che ti costa denaro per chiamata, come uno che innesca un LLM. Limita per IP per il traffico anonimo e per utente o chiave API per il traffico autenticato. Quando il limite e superato, restituisci un 429 e fermati.

// Un limiter a finestra fissa minimale. In produzione, usa uno store condiviso
// (Redis, Upstash o il tuo DB) perche funzioni su piu server.
const hits = new Map<string, { count: number; resetAt: number }>()

export function rateLimit(key: string, max = 10, windowMs = 60_000) {
  const now = Date.now()
  const entry = hits.get(key)
  if (!entry || now > entry.resetAt) {
    hits.set(key, { count: 1, resetAt: now + windowMs })
    return { ok: true }
  }
  if (entry.count >= max) return { ok: false, retryAfter: entry.resetAt - now }
  entry.count += 1
  return { ok: true }
}

// Nel tuo handler :
// const limit = rateLimit(`login:${ip}`, 5, 60_000)
// if (!limit.ok) return new Response('Too many requests', { status: 429 })

Header CSP e cifrare le credential memorizzate

Una Content Security Policy dice al browser esattamente quali fonti ha il diritto di caricare per script, stili e immagini. E la tua difesa piu forte contro il cross-site scripting: anche se un attaccante inietta un tag script, il browser rifiuta di eseguirlo perche la fonte non e sulla tua allowlist. Parti stretto e allenta solo cio che devi. Separatamente, tutto cio che memorizzi di sensibile - una chiave API di terzi, un token OAuth, un segreto utente - deve essere cifrato a riposo, perche un'intrusione in database consegni testo cifrato, non credential funzionanti. La chiave di cifratura stessa vive in una variabile d'ambiente, mai nel database che protegge.

Content-Security-Policy: default-src 'self';
  script-src 'self';
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  connect-src 'self' https://api.your-provider.com;
  frame-ancestors 'none';
  base-uri 'self'

• default-src 'self' vuol dire: salvo indicazione contraria, caricare solo dal tuo dominio.
• connect-src controlla quali API il browser ha il diritto di chiamare - elenca solo i tuoi veri backend.
• frame-ancestors 'none' impedisce ad altri siti di incorporare la tua in un iframe (clickjacking).
• Cifra i segreti memorizzati con una libreria, non a mano; tieni la chiave in una env var, falla ruotare se un giorno trapela.

Audit log: sapere chi ha fatto cosa

Quando qualcosa va male - un rimborso emesso, un account cancellato, un piano retrocesso - devi rispondere "chi l'ha fatto, quando e da dove". Un audit log e un record in append-only delle azioni sensibili: l'attore, l'azione, il target, un timestamp e l'IP sorgente. Non e la stessa cosa dei tuoi log applicativi; e una traccia deliberata per la sicurezza e la responsabilita. Logga ogni azione che sposta denaro, cambia permessi o tocca i dati di un altro utente. Non loggare mai i segreti stessi, solo che l'azione ha avuto luogo.

La checklist pre-pubblica di repo

E quella che morde piu forte. Cancellare una chiave dal tuo commit piu recente non la toglie dalla cronologia - siede ancora in un vecchio commit che tutti possono leggere appena il repo passa in pubblico. Prima di passare un repo da privato a pubblico, percorri questa checklist ogni volta. Se trovi un segreto nella cronologia, la sola mossa sicura e trattare quel segreto come compromesso: fallo ruotare immediatamente, poi ripulisci la cronologia.

• Scansiona la cronologia completa per i segreti, non solo i file attuali. Usa uno strumento come gitleaks o trufflehog: gitleaks detect --source . coglie chiavi, token e password su ogni commit.
• Conferma che .env e ogni file di segreto sono in .gitignore e non sono mai stati committati.
• Verifica le chiavi in chiaro, gli URL interni, i dati clienti e le credential nel codice e nei commenti.
• Se un segreto e mai stato committato: fallo ruotare prima (supponilo gia pubblico), poi riscrivi la cronologia per toglierlo prima di passare in pubblico.
• Solo dopo una scansione pulita passi il repo in pubblico.

# Auditare tutta la cronologia Git per i segreti trapelati prima di passare in pubblico
gitleaks detect --source . --verbose

# Se qualcosa e trovato, FAI RUOTARE il segreto prima, poi ripulisci la cronologia.

Errori frequenti

I ricorrenti: pubblicare un endpoint di IA o di e-mail senza rate limit e svegliarsi davanti a una fattura a cinque cifre; memorizzare i token di terzi in chiaro, cosicche una fuga compromette ogni account connesso; saltare la CSP perche e noiosa e poi ingoiare un XSS; e il classico - passare un repo in pubblico per "condividere il progetto" senza auditare la cronologia, e far trapelare una chiave che ci sta da mesi. Ognuno e evitato da un'abitudine di questa lezione.

ROI business

La sicurezza e invisibile quando funziona e catastrofica quando non funziona. Una chiave trapelata puo svuotare un budget dall'oggi al domani, un'intrusione nelle credential memorizzate puo mettere fine a un'azienda, e una sola fuga di repo pubblico e costata ai fondatori denaro reale e veri clienti. Gli essenziali qui ti costano un pomeriggio da mettere in atto poi girano per sempre. Per una squadra pilotata da agente, cio conta doppio: gli agenti generano endpoint in fretta, quindi la disciplina "ogni endpoint pubblico riceve un rate limit, ogni segreto e cifrato, ogni repo e auditato" deve essere una regola che l'agente segue, non qualcosa che ricordi.

Checklist

Conferma ognuno di questi punti prima di dirigere veri utenti su qualsiasi cosa tu abbia costruito.

• Ogni endpoint pubblico e costoso ha un rate limit che restituisce 429 in caso di superamento.
• Un header Content Security Policy e posto e stretto quanto la tua app permette.
• Le credential e i token memorizzati sono cifrati a riposo, la chiave in una env var.
• Hai fatto girare una scansione di segreti su tutta la cronologia prima di ogni repo pubblico e fatto ruotare tutto cio che e stato trovato.

Risorse

Tieni gitleaks o trufflehog installato e aggiungi la scansione di cronologia al tuo rituale pre-pubblico. Il OWASP Top 10 e la reference CSP di MDN sono le fonti senza tempo quando hai bisogno di profondita. Metti "rate-limita questo endpoint" e "cifra questo segreto memorizzato" nelle tue regole di progetto, perche gli agenti le applichino senza che si chieda.

La tua missione

Aggiungi un rate limit a un vero endpoint e conferma che restituisce 429 quando lo superi. Poni un header CSP sulla tua app e correggi cio che rompe, finche la pagina funziona sotto una policy stretta. Poi fai girare gitleaks contro uno dei tuoi repo e leggi l'output - anche un risultato pulito ti insegna a fidarti della verifica prima di passare un giorno in pubblico.

Prossima lezione

Sicuro e indurito, la prossima lezione tratta il diritto e la conformita: GDPR, consenso cookie conforme incluso Global Privacy Control, e le leggi di protezione dei dati statunitensi e svizzere, spiegate senza mal di testa.