Skip to content

README-it.md

Latest commit

 

History

History
122 lines (90 loc) · 8.13 KB

README-it.md

File metadata and controls

122 lines (90 loc) · 8.13 KB

English | 繁中版 | 简中版 | العربية | Azərbaycan | Български | বাংলা | Català | Čeština | Deutsch | Ελληνικά | Español | فارسی | Français | हिंदी | Indonesia | 日本語 | 한국어 | ພາສາລາວ | Македонски | മലയാളം | Монгол | Nederlands | Polski | Português (Brasil) | Русский | ไทย | Türkçe | Українська | Tiếng Việt

Checklist per la sicurezza delle API

Una checklist per le più importanti contromisure da mettere in pratica quando strutturiamo, testiamo e rilasciamo le nostre API.

Autenticazione

  • Non usare la Basic Auth Utilizzare piuttosto dei sistemi standard di identificazione.
  • Non re-inventarsi sistemi di autenticazione, generazione token, salvataggio password. Utilizzare gli standard.
  • Utilizzare Max Retry e le jail features per il Login.
  • Utilizzare la cifratura per tutti i dati sensibili.

Accesso

  • Limitare le richieste (Throttling) per evitare attacchi DDoS o brute-force.
  • Utilizzare il protocollo HTTPS per evitare attacchi MITM (Man In The Middle Attack).
  • Utilizzare l'header HSTS per evitare attacchi SSL Strip.
  • Disattiva gli elenchi di directory.
  • Per le API private, consenti l'accesso solo da IP/host nella whitelist (lista bianca).

Autorizzazione

OAuth

  • Validare sempre il valore di redirect_uri lato server permettendo solo url verificati nella whitelist.
  • Tentare sempre lo scambio attraverso il codice e non tramite token (non permettere response_type=token).
  • Utilizzare il parametro state con un hash random per prevenire il CSRF durante il processo di autenticazione OAuth.
  • Definire lo scope di default e validare i parametri dello scope per ogni singola applicazione.

Input

  • Utilizzare il metodo HTTP appropriato in base all'azione: GET (lettura), POST (scrittura), PUT/PATCH (sostituzione/modifica), e DELETE (cancellazione), e rispondere con uno status 405 Method Not Allowed se il metodo della richiesta non è appropriato.
  • Validare il content-type rispetto all' Accept header (Content Negotiation) per consentire solo i formati supportati (es. application/xml, application/json, ecc.) e rispondere con un 406 Not Acceptable se la risposta non coincide.
  • Validare il content-type in base alle strutture accettate (es. application/x-www-form-urlencoded, multipart/form-data, application/json, ecc.).
  • Validare sempre gli input dell'utente per evitare attacchi comuni (es. XSS, SQL-Injection, Remote Code Execution, ecc.).
  • Non utilizzare mai dati sensibili (credenziali, password, security tokens, o API keys) nell'url, utilizzare piuttosto gli Authorization header.
  • Utilizzare solo la crittografia lato server.
  • Utilizzare un gateway per abilitare il caching delle API, con sistema di controllo delle chiamate (es. Quota, Spike Arrest, Concurrent Rate Limit).

Processing

  • Verificare che tutti gli endpoints siano protetti dal sistema di autenticazione, per evitare eventuali falle.
  • L'ID dell'utente corrente andrebbe sempre evitato nelle url. Utilizzare ad esempio /me/orders piuttosto che /user/654321/orders.
  • Non ricorrere all'autoincremento di un ID. Utilizzare piuttosto un UUID.
  • Se stai effettuando il parsing di un file XML, controlla che l'entity parsing non sia attiva per evitare XXE (XML external entity attack).
  • Se stai effettuando il parsing di un file XML, controlla che l'entity expansion non sia attiva per evitare il Billion Laughs/XML bomb.
  • Utilizzare una CDN per l'upload dei file.
  • Se stai gestendo grandi moli di dati, utilizza Workers e Queues per processare i dati in background evitando che la chiamata HTTP vada in blocco.
  • Ricordarsi sempre di disattivare le eventuali modalità di DEBUG.
  • Utilizzare stack non eseguibili quando disponibili.

Output

  • Inviare l'header X-Content-Type-Options: nosniff.
  • Inviare l'header X-Frame-Options: deny.
  • Inviare l'header Content-Security-Policy: default-src 'none'.
  • Rimuovere header che permettono il riconoscimento - X-Powered-By, Server, X-AspNet-Version ecc.
  • Forzare il content-type nella chiamata di risposta: se per esempio viene ritornato un application/json forzare il content-type a application/json.
  • Do not return overly specific error messages to the client that could reveal implementation details, use generic messages instead, and log detailed information only on the server side.
  • Non ritornare mai dati sensibili come credenziali, password, security tokens.
  • Ritornare sempre lo status code corretto in base all'esito della chiamata. (es. 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, ecc).

CI & CD

  • Verificare il design attraverso gli unit/integration tests.
  • Definire e utilizzare una procedura di code review per il rilascio, evitando l'auto approvazione.
  • Verificare che tutti i componenti dei servizi siano controllati da software AV prima di essere messi in produzione, incluse le librerie di terze parti.
  • Esegui continuamente test di sicurezza (analisi statica/dinamica) sul tuo codice.
  • Controlla le tue dipendenze (sia software che sistema operativo) per le vulnerabilità note.
  • Definire una strategia di rollback per il deploy.

Monitoraggio

  • Utilizza accessi centralizzati per tutti i servizi e i componenti.
  • Utilizza gli agenti per monitorare tutto il traffico, gli errori, le richieste, e le risposte.
  • Utilizza gli avvisi per SMS, Slack, Email, Telegram, Kibana, Cloudwatch, ecc.
  • Assicurati di non registrare dati sensibili come carte di credito, password, PIN, ecc.
  • Utilizza un sistema IDS e/o IPS per monitorare le richieste e le istanze della tua API.

Guarda anche:

API Security Best Practices (Advanced)

Rate Limiting & Abuse Prevention

  • Implement sliding window rate limiting per API key and IP.
  • Use exponential backoff for repeated failed authentication attempts.
  • Implement CAPTCHA or proof-of-work challenges after suspicious activity.
  • Monitor and alert on unusual API usage patterns (time, volume, endpoints).

GraphQL-Specific Security

  • Disable introspection in production environments.
  • Implement query depth limiting to prevent nested query attacks.
  • Use query cost analysis to prevent resource exhaustion.
  • Whitelist allowed queries in production when possible.

Secrets Management

  • Rotate API keys and secrets on a regular schedule.
  • Use hardware security modules (HSM) for signing operations.
  • Implement secret scanning in CI/CD pipelines.
  • Never commit secrets to version control - use environment variables or secret managers.

Zero Trust Architecture

  • Implement mutual TLS (mTLS) for service-to-service communication.
  • Validate all requests even from internal services.
  • Use short-lived tokens with automatic refresh.
  • Implement request signing for sensitive operations.

Contribuire

Siate liberi di contribuire a questo progetto facendo un fork, modificandolo e inviando una pull request. Per qualsiasi dubbio inviare un'email all'indirizzo: team@shieldfy.io.