Un’applicazione Node.js sicura è un’applicazione che protegge i dati degli utenti e l’integrità del sistema prevenendo attacchi comuni (come injection e account takeover), riducendo l’esposizione accidentale dei dati e tenendo i comportamenti rischiosi fuori dal runtime e dalle dipendenze.
Questa è una guida fondazionale per sviluppatori e team lead che vogliono applicare le migliori pratiche per applicazioni Node.js sicure fin dall’inizio. Si concentra su abitudini pratiche e ripetibili che innalzano la baseline di sicurezza senza trasformare il progetto in uno sforzo di ricerca sulla sicurezza.
Punti chiave (fare prima queste)
- Validare ogni input con uno schema rigoroso.
- Usare parameterized queries; non concatenare mai input utente nelle query.
- Hash delle password con Argon2id quando supportato (bcrypt è un fallback maturo).
- Usare sessioni e token sicuri (cookie flags, JWT hygiene).
- Applicare protezioni di base come security headers e un CORS allowlist rigoroso.
- Praticare la logging hygiene: registrare eventi di sicurezza, mai segreti o token.
- Automatizzare i controlli su dipendenze e sicurezza — e considerarli segnali, non garanzie.
Baseline di sicurezza per app Node.js (iniziare qui)
Iniziare con una baseline pulita. La maggior parte delle violazioni non avviene perché un team ha perso una tecnica avanzata, ma perché default insicuri sono rimasti in vigore troppo a lungo.
- Usare una versione Node.js LTS supportata per il production work.
- Mantenere runtime e dipendenze aggiornati.
- Separare la configurazione di sviluppo e produzione (feature flags, env vars, livelli di logging).
- Disabilitare disclosure non necessari del server come
x-powered-by. - Non esporre stack traces nelle risposte di produzione.
Per una checklist ufficiale sintetica, vedere Node.js security best practices.
Esempio: disabilitare il disclosure del server e sanificare gli errori
// Express example
app.disable('x-powered-by');
app.use((err, req, res, next) => {
req.log?.error({ err }, 'Unhandled error');
res.status(500).json({ error: 'Something went wrong.' });
});Validare l’input e prevenire injection
Iniziare dai principi, poi scegliere gli strumenti.
Principio 1: validare al confine
Validare l’input il prima possibile — prima della business logic e prima di qualsiasi chiamata al database. Librerie di schema validation come Joi o Zod possono aiutare, ma l’idea centrale è la stessa: accettare solo ciò che ci si aspetta.
Principio 2: usare parameterized queries
Evitare di costruire query string con input utente. Usare parameterized queries tramite ORM o query builder. Prisma, Drizzle, Knex e la maggior parte dei database client maturi supportano la parametrizzazione.
Principio 3: encodare l’output in base al contesto
Se l’applicazione renderizza contenuti generati dagli utenti, encodare l’output in base a dove verrà usato (HTML, attributi, URL). Menzionare HTML sanitizer come DOMPurify solo se l’applicazione accetta o renderizza realmente HTML.
Esempio: schema validation al confine API
// Zod example (library choice is optional)
const { z } = require('zod');
const createUserSchema = z.object({
email: z.string().email(),
password: z.string().min(12).max(128),
});
const parsed = createUserSchema.safeParse(req.body);
if (!parsed.success) {
return res.status(400).json({ error: 'Invalid input.' });
}Implementare correttamente autenticazione e sicurezza delle sessioni
Gli errori di autenticazione possono trasformare un piccolo bug in un compromissione completa dell’account. Mantenere l’implementazione noiosa e ben compresa.
Password hashing: Argon2id preferito, bcrypt come fallback
Preferire Argon2id quando lo stack lo supporta. bcrypt è un fallback maturo quando Argon2id non è disponibile o quando serve compatibilità con un password store esistente.
Per indicazioni sulla scelta sicura dei parametri, vedere OWASP password storage guidance.
Sessioni e token sicuri
- Usare cookie flags dove applicabile:
httpOnly,secure,sameSite. - Trattare i JWT come credenziali di breve durata. Evitare di inserire dati sensibili nel payload.
- Evitare pattern di storage deboli che espongono i token a XSS.
Aggiungere MFA per gli account admin
Anche se non si impone MFA per ogni utente, imporla per gli account admin e ad alto privilegio.
Rate limiting per gli endpoint di login e token
const rateLimit = require('express-rate-limit');
const authLimiter = rateLimit({
windowMs: 15 * 60 * 1000,
max: 5,
standardHeaders: true,
});
app.post('/auth/login', authLimiter, loginHandler);Se si vuole andare oltre le basi verso un programma completo di sicurezza in produzione, vedere la guida avanzata sulla sicurezza di Node.js in produzione.
Gestire segreti e dati sensibili in modo sicuro
- I file
.envvanno bene per lo sviluppo locale, ma non sono una soluzione di gestione dei segreti per la produzione. - In produzione, preferire un secret store come KMS, Secrets Manager, Vault o la gestione dei segreti integrata della piattaforma.
- Usare HTTPS e cifrare i dati sensibili a riposo dove appropriato.
- Non registrare mai segreti, password, token o corpi di richiesta completi per default.
Per una prospettiva più ampia sulle pratiche a livello di programma, vedere la guida sulla gestione della sicurezza dei dati.
Aggiungere controlli di sicurezza al workflow di sviluppo
Usare npm audit (ma non affidarsi solo a questo)
npm audit è utile per scoprire vulnerabilità note, ma non basta da solo. Considerarlo un segnale tra molti.
Aggiungere controlli leggeri
- Plugin di sicurezza ESLint (per intercettare pattern rischiosi comuni)
- SAST scanning di base (almeno sulle pull request)
- Unit test per le regole di autorizzazione (route critiche)
- Una semplice PR security checklist (input, authz, segreti, logging)
Checklist per applicazioni Node.js sicure
- Usare una versione Node.js LTS supportata.
- Mantenere le dipendenze aggiornate e rimuovere i pacchetti non utilizzati.
- Validare gli input con schemi rigorosi.
- Usare parameterized queries ed evitare la concatenazione di stringhe.
- Hash delle password con Argon2id (bcrypt come fallback).
- Applicare cookie flags sicuri e JWT hygiene.
- Impostare security headers di base e CORS allowlist rigorosi.
- Non esporre stack traces in produzione.
- Non registrare segreti, token o payload sensibili.
- Eseguire
npm auditregolarmente e considerarlo un punto di partenza. - Aggiungere controlli di sicurezza di base a CI e PR review.
Domande frequenti
Quali sono le migliori pratiche per applicazioni Node.js sicure?
Le migliori pratiche mirano a ridurre la superficie d’attacco fin dal primo giorno: validare tutti gli input, usare parameterized queries, hash delle password con Argon2id (o bcrypt), proteggere sessioni e token, impostare security headers e CORS rigoroso, tenere i segreti fuori da codice e log e automatizzare i controlli su dipendenze e sicurezza nel workflow.
Node.js è sicuro di default?
Node.js non è intrinsecamente insicuro, ma la sicurezza dipende dal codice e dalla configurazione dell’applicazione. Un’applicazione Node.js sicura richiede default intenzionali per validazione input, autenticazione, gestione degli errori, gestione dei segreti e manutenzione delle dipendenze.
Qual è il modo migliore per salvare le password in Node.js?
Preferire Argon2id quando lo stack lo supporta. bcrypt è un fallback maturo e ampiamente compatibile. Non salvare mai password in chiaro ed evitare hash veloci come MD5 o SHA1 per lo storage delle password.
Come si validano gli input nelle API Node.js?
Validare al confine del sistema con uno schema rigoroso (ad esempio con librerie come Joi o Zod). Combinare la validazione dello schema con parameterized queries e output encoding contestuale per ridurre il rischio di injection e XSS.
Come si rende sicura l’autenticazione JWT in Node.js?
Mantenere JWT di breve durata, evitare di memorizzare dati sensibili nel payload e scegliere pattern sicuri di storage e trasporto. Usare secure cookies quando appropriato, implementare la rotazione dei token dove necessario e applicare rate limiting agli endpoint di login e token.
npm audit è sufficiente?
No. npm audit è utile per scoprire vulnerabilità note, ma non garantisce la sicurezza complessiva dell’applicazione. Abbinarlo a pratiche di secure coding, testing e processi di review per ridurre il rischio reale.
Conclusione
Lo sviluppo sicuro in Node.js riguarda soprattutto fondamenta coerenti: validare gli input, proteggere l’autenticazione, tenere i segreti fuori da codice e log e inserire i controlli di sicurezza nel workflow. Iniziare con le pratiche di baseline di questa guida, poi salire di livello man mano che l’applicazione cresce.
Se serve aiuto per costruire un’applicazione Node.js sicura con solide fondamenta ingegneristiche, HDWEBSOFT offre servizi di sviluppo Node.js.
