Tre anni fa il vostro team ha costruito un’integrazione di pagamento. Funzionava perfettamente. Poi siete passati a una soluzione migliore, avete rilasciato la nuova versione e tutti si sono dedicati al progetto successivo. Nessuno ha aperto un ticket formale per disattivare il vecchio endpoint. Nessuno ci ha nemmeno pensato.
Quell’endpoint probabilmente sta ancora girando adesso. Benvenuti nel problema delle Zombie API.
Cosa sono le Zombie API
Una Zombie API è un’interfaccia applicativa che rimane accessibile ma che l’organizzazione non monitora più, non aggiorna e non supporta ufficialmente. Continua a funzionare in background, risponde alle richieste, restituisce dati — ma nessuno la presidia. Può trattarsi di:
- Un’API versione 1 dimenticata dopo il lancio della v2
- Un endpoint di test mai rimosso dall’ambiente di produzione
- Un’integrazione con un sistema esterno deprecato ma mai formalmente chiusa
- Un servizio interno esposto durante uno sprint e poi lasciato lì
La differenza rispetto alle Shadow API è sottile ma importante: le Shadow API sono endpoint mai documentati ufficialmente (spesso creati da sviluppatori senza seguire i processi aziendali); le Zombie API sono endpoint che erano ufficiali, ma sono sopravvissute alla loro utilità.
Perché le Zombie API sono pericolose
1. Controlli di sicurezza obsoleti
Le Zombie API nascono in un’epoca diversa. Possono ancora utilizzare meccanismi di autenticazione deboli come API key in plaintext, HTTP Basic Auth senza HTTPS, o sessioni senza scadenza. Non hanno mai ricevuto le patch per le vulnerabilità scoperte negli anni successivi alla loro creazione. I framework e le librerie che usano sono datati, spesso con CVE note e non risolte.
# Esempio: vecchio endpoint con autenticazione debole
GET /api/v1/payments?user_id=1234&token=abc123
# Nessuna validazione token server-side, nessun rate limiting,
# nessun log di accesso attivo
2. Assenza di monitoraggio
Gli endpoint zombie non compaiono nei dashboard di osservabilità, non generano alert, non vengono inclusi nei penetration test periodici. Eppure continuano a restituire dati: record di clienti, token di sessione, informazioni di sistema. Le violazioni che li coinvolgono possono passare inosservate per mesi.
3. Superficie di attacco invisibile
Dal punto di vista del team di sicurezza, l’endpoint non esiste. Dal punto di vista di un attaccante, invece, è perfettamente raggiungibile. Gli scanner automatici — e nel 2026 sempre più spesso gli agenti AI autonomi — individuano questi endpoint attraverso pattern comuni: /api/v1/, /api/legacy/, file Swagger dimenticati, entry in file robots.txt.
4. Il vettore degli agenti AI
Una dimensione nuova nel 2026: i sistemi agentic AI che chiamano autonomamente API per completare task possono scoprire e interagire con endpoint zombie che il team di sicurezza umano non ha mai pensato di inventariare. Un agente che esegue fuzzing automatico o che segue link nei file di documentazione può “risvegliare” endpoint che nessuno controllava da anni.
Come identificare le Zombie API nel vostro ambiente
Inventario tramite discovery automatica
Il primo passo è vedere ciò che non si riesce a vedere. Strumenti come OWASP ZAP, Burp Suite, o soluzioni enterprise come Noname Security, Salt Security e Traceable AI possono scansionare il traffico di rete per identificare endpoint che ricevono richieste ma non compaiono nella documentazione ufficiale.
# Con curl e grep: cerca pattern di API versionate nei log
grep -E "/api/v[0-9]+/" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -50
Analisi del codice sorgente
Una scansione statica del codice può estrarre tutti i route definiti nell’applicazione e confrontarli con quelli registrati nel gateway API. La differenza è la lista candidata di zombie (o shadow).
# Esempio con grep per trovare route Express.js
grep -rE "app\.(get|post|put|delete|patch)\s*\(" ./src | grep -oP "(?Analisi del traffico reale
Anche se un endpoint non viene più mantenuto, potrebbe ancora ricevere traffico — da client legacy, da integrazioni di partner non aggiornate, o da attaccanti che lo scandagliano. Analizzare i log di accesso degli ultimi 90-180 giorni rivela endpoint “morti” che in realtà rispondono ancora.
Come mitigare il rischio
Governance del ciclo di vita delle API
La soluzione strutturale è implementare un API lifecycle management formale, con quattro fasi chiare:
- Active: l’API è in produzione, monitorata e manutenuta
- Deprecated: l’API funziona ancora ma è stata annunciata la dismissione. I client ricevono header
DeprecationeSunsetin ogni risposta - Sunset: la data di dismissione è imminente, le richieste restituiscono warning espliciti
- Retired: l’endpoint è stato disattivato, risponde con 410 Gone
# Header HTTP di deprecazione (RFC 8594)
HTTP/1.1 200 OK
Deprecation: Sat, 31 Dec 2025 23:59:59 GMT
Sunset: Sat, 30 Jun 2026 23:59:59 GMT
Link: <https://api.example.com/v2/payments>; rel="successor-version"
Applicate il principio del minimo privilegio anche alle API
Le API che non sono più in uso attivo non dovrebbero avere accesso ai sistemi di produzione. Prima di decommissionare formalmente, rimuovete le credenziali, revocate i token di accesso e isolate l’endpoint dalla rete interna.
Automatizzate il testing di sicurezza su tutto l’inventario
Il penetration test periodico deve includere anche gli endpoint “vecchi”. Configurate scanner DAST (Dynamic Application Security Testing) per coprire l’intero inventario API, non solo gli endpoint documentati nella versione corrente.
# Esempio con OWASP ZAP via CLI
docker run -t owasp/zap2docker-stable zap-api-scan.py -t https://api.example.com/api/v1/openapi.yaml -f openapi -r zap-report.html
Risk scoring degli endpoint
Non tutti gli endpoint zombie hanno lo stesso livello di rischio. Prioritizzate in base a:
- Metodo di autenticazione (nessuna > API key > OAuth 2.0)
- Sensibilità dei dati esposti (PII, dati finanziari, credenziali)
- Esposizione a traffico esterno vs. solo interno
- Presenza di vulnerabilità note nel framework usato
- Volume e origine del traffico recente
Un piano d’azione in tre settimane
Per team che vogliono affrontare il problema in modo pragmatico:
Settimana 1 — Discovery: Eseguite una scansione completa del traffico degli ultimi 90 giorni. Estraete tutti gli endpoint dal codice sorgente. Confrontate con il registro ufficiale dell’API gateway.
Settimana 2 — Triage: Per ogni endpoint non documentato, determinate se è un’API shadow (mai documentata) o zombie (precedentemente documentata). Applicate il risk scoring. Identificate i proprietari originali tramite git blame o cronologia dei ticket.
Settimana 3 — Remediation: Gli endpoint ad alto rischio vanno disabilitati immediatamente. Per quelli con traffico ancora attivo, notificate i client e stabilite una data di sunset. Implementate il processo di governance per prevenire il problema in futuro.
Conclusione
Le Zombie API non sono un problema teorico. Sono un debito tecnico e di sicurezza reale, spesso invisibile, che cresce silenziosamente ad ogni rilascio. Con l’aumento dei sistemi agentic AI che interagiscono autonomamente con le API, il rischio di “risvegliare” questi endpoint aumenta ulteriormente.
La buona notizia è che il problema è risolvibile con processi ben definiti: discovery sistematico, governance del ciclo di vita, e testing automatizzato su tutto l’inventario — non solo sulla versione corrente dell’API.
Non aspettate che sia un attaccante a scoprire cosa avete dimenticato.
Fonte originale: The “Zombie API” Attack: Why Your Old Integrations Are Your Biggest Security Risk (DZone) — approfondito con riferimenti da Salt Security, GetAstra e Checkmarx.