Servizi connessi

Progetta API e integrazioni affidabili con contratti chiari, accessi controllati e gestione degli errori.

52 articoli · Ultimo articolo aggiornato

La ricerca copre tutti gli articoli di questa sezione, inclusi l’archivio e il testo degli articoli.

Comprendere l'argomento

Una guida pratica a questo argomento

Una funzionalità connessa dipende da identità, contratti di interfaccia, fornitori e modalità di errore. Questa categoria collega la progettazione delle API, la sicurezza, la continuità e la qualità del servizio ricevuto dagli utenti.

Cosa esaminare
  • Identificare le chiamate essenziali per ogni percorso e i relativi responsabili.
  • Pianificare scadenze, errori, tentativi sicuri e degrado visibile.
  • Simulare interruzioni, ripristino e risposta agli incidenti.
  • Confrontare le risposte effettive con il contratto documentato prima di modificare un'interfaccia.
  • Testare i diritti su ogni oggetto e campo GraphQL, quindi vincolare nidificazione, elenchi e alias in base al costo effettivo.
  • Trasforma una notifica ricevuta in un effetto aziendale univoco e tracciabile, recuperabile dopo un errore.
  • Separare le cache condivise, private e dell'applicazione, ispezionare le chiavi, la convalida e l'invalidazione dopo le modifiche dei diritti di accesso.
  • Importare un URL può esporre involontariamente risorse interne.
  • I limiti condizionano capacità, ritentativi e distribuzione tra clienti.
  • Controllare cosa viene letto, quando continuare e come dimostrare la copertura.
  • I file ricevuti vanno verificati prima di pubblicazione o elaborazione.
  • Una cache condivisa deve separare contenuto pubblico e risposte personali.
  • Accettare una richiesta non dimostra che il lavoro sia concluso.
  • Distinguere eventi prodotti, ricevuti e utilizzabili senza leggere il silenzio come assenza di incidenti.
  • Definire un contratto per messaggi di iframe o popup che rifiuti mittenti e dati inattesi.
  • Validare percorsi, collegamenti e dati espansi prima di promuovere i file estratti.
  • Seguire il rinnovo fino ai punti di terminazione e ai client prima di chiudere il cambiamento.
Domande utili
  • Cosa succede se un provider smette di rispondere?
  • Un tentativo di ripetizione può ripetere un'azione?
  • Quali prove dimostrano che il ripristino funziona?
  • Quali client esistenti sarebbero interessati da una nuova versione?
  • Un resolver può restituire un campo privato dopo che il suo genitore ne ha consentito l'accesso?
  • Quali byte sono firmati?
  • L'assenza di cache significa che non viene conservato nulla?
  • Basta verificare la prima URL?
  • 429 dimostra che una scrittura precedente non è avvenuta?
  • Una pagina vuota conclude l’esportazione?
  • Un’estensione consentita dimostra che il file è sicuro?
  • Un cookie impedisce la cache condivisa?
  • 202 dimostra che il lavoro terminerà?
  • Tre righe ricevute provano tre eventi conservati?
  • Basta controllare event.origin?
  • Un archivio piccolo o un filtro garantisce sicurezza?
  • Il rinnovo ACME riuscito è sufficiente?

Esempio di decisione illustrativa

Situazione
Esempio fittizio: questi dati non descrivono clienti o risultati osservati. Due letture sono veloci, ma una mostra ancora una disponibilità precedente dopo una modifica alla fonte.
Verifica
Confrontare valore, versione, punto di lettura e tempo dalla modifica. Provare invalidazione, scadenza e accesso alla fonte secondo il contratto del sistema.
Agisci
Definire l’anzianità accettabile dei dati per ogni uso e sorvegliare le divergenze. Minore latenza non dimostra coerenza dei dati serviti.

Cache API: controllare freschezza, isolamento e coerenza

Cache HTTP: proteggere le risposte personalizzate

IETF — RFC 9111, HTTP Caching

Verificare il destinatario e le autorizzazioni.

Un token firmato non autorizza automaticamente un'operazione su un oggetto. Testare l'emittente, il pubblico, la scadenza e l'accesso tra account; aggiungere i rifiuti previsti insieme ai casi di successo.

Un token valido per un'altra API o ruolo viene effettivamente rifiutato?

Esplora i metodi

Leggere i dati e decidere

Tentativi API: contare l’intero budget di tempo

Quattro tentativi comprendono tre ripetizioni.

Tentativi totali
41 + 3
Attese accumulate (ms)
700100 + 200 + 400
Budget modellato (ms)
17004 × 250 + 700

Caso didattico fittizio: i numeri non rappresentano CIE o clienti.

Provare un budget di tentativi

n × T + W × (2^(n−1) − 1)

Domande per preparare le decisioni

Risposte e verifiche pratiche nelle analisi di questa sezione.

Esplora l’archivio

Altre analisi sul tema, oltre agli articoli recenti elencati qui sotto.

Riferimenti: dati, usi e limiti

Documentazione consultata il .

Le note dettagliate di questa edizione sono disponibili in inglese.

Threat intelligence: content, exchange and sharingThree distinct functions. STIX 2.1 · Describe. TAXII 2.1 · Exchange. TLP 2.0 · Share. None establishes truth alone. Objects and relationships. Collections and protocol. Permitted recipients. Local validation: origin, period, relevance and permissions.Threat intelligence: content, exchange and sharingThree distinct functionsNone establishes truth aloneSTIX 2.1 · DescribeObjects and relationshipsTAXII 2.1 · ExchangeCollections and protocolTLP 2.0 · SharePermitted recipientsLocal validation: origin, period, relevance and permissions
Threat intelligence: content, exchange and sharing
Riferimenti: dati, usi e limiti
Fonte e finalitàDato o riferimento verificatoCome utilizzarloLimite da conservare
MITRE · Common Weakness Enumeration

Name classes of software and hardware weakness.

 A CWE describes a weakness that can contribute to vulnerabilities. It does not represent a particular incident. Connect the weakness to the observed mechanism: input, processing and missing control. Use it to fix the cause and plan regression tests.

Approfondire il metodo →

 A keyword in a report alone does not establish the correct CWE classification.
OASIS · STIX 2.1

Describe threat intelligence through structured objects and relationships.

 STIX 2.1 is an OASIS Standard dated 10 June 2021. It defines objects, properties and JSON serialisation. Keep identifiers, dates, provenance and relationships. Check that the recipient interprets the same object type and validity period.

Approfondire il metodo →

 A syntactically valid object can still be stale, misattributed or weakly supported.
OASIS · TAXII 2.1

Exchange threat intelligence through an application protocol.

 TAXII 2.1 is an OASIS Standard dated 10 June 2021. It includes service discovery and access to collections. Test authentication, collection permissions, pagination and recovery after interruption. Record which objects were actually received and processed.

Approfondire il metodo →

 TAXII transports data; it replaces neither the content model nor assessment of reliability.

Identità: fattori, sessioni e recupero

Le note dettagliate di questa edizione sono disponibili in inglese.

Identity APIs: separate authentication and authorisation

A valid token identifies a session or identity under its protocol. It does not automatically grant access to every business object. Recovery and revocation must be checked on the consuming backend.

  • Check applicable issuer, audience, expiry and permissions.
  • Replay access to an unauthorised object and a revoked session.
  • Record useful decisions without logging authentication secrets.

Open the authenticator and recovery comparison →

Sources consulted on · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3

ETag, cache HTTP e modifiche concorrenti

Le note dettagliate di questa edizione sono disponibili in inglese.

Specify conflicts in the API contract

The contract should explain which validator accompanies a representation and how clients handle refusals.

  • State whether PUT requires a conditional field and when 428 is issued.
  • Document strong If-Match, 412 and the conflict-resolution journey.
  • Support HEAD and 304 without content and test SDK behaviour.

Explore ETag comparisons and the simulator →

References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3

Retry-After: attesa, budget e nuovi tentativi

Le note dettagliate di questa edizione sono disponibili in inglese.

Specify permission to repeat before retry timing

Retry-After describes waiting. The contract must also define replayable operations, keys, versions and unknown-result states.

  • State whether the field is seconds or a date and how clients handle absent or invalid values.
  • Name the retry controller and global budget to prevent overlapping attempts.
  • Retain parameters, context and the idempotency window without generalising Stripe to every API.

Explore Retry-After and the retry model →

References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS

Esplora il catalogo KEV di CISA

Le note dettagliate di questa edizione sono disponibili in inglese.

One identifier can span several technical layers

An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.

  • Connect the CVE, component supplier and final-product supplier.
  • Check version, configuration and execution path in the authorised environment.
  • Do not infer remediation from an empty search result.

Esplora il catalogo e il metodo →

CISA KEV · 2026.10.21 · Documentary review : 2026-10-22

Estensioni: permessi e accesso

Le note dettagliate di questa edizione sono disponibili in inglese.

Robust authentication does not describe extension access

Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.

  • Test approved extensions in a profile dedicated to sensitive operations.
  • For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
  • Distinguish session revocation, token revocation, extension disablement and native-component removal.

Read the permission directory and manifest examples →

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Codici syslog e prove di raccolta

Le note dettagliate di questa edizione sono disponibili in inglese.

Normalisation must preserve event meaning

In a distributed API, a PRI integer combines two codes. An opaque conversion may lose the message family or reverse severity. Test collection with identified events before inferring operational reliability.

  • Keep facility, severity and raw value in separate fields.
  • Distinguish source time, reception time and search availability.
  • Expose rejected events, truncation, loss and conversion rules.

Read syslog codes and try the PRI calculation →

IANA · syslog Parameters · Registry updated 2016-04-26 · consulted 2026-10-23

ASD ACSC and partners · Best practices for event logging and threat detection · Published and reviewed 2024-08-22 · consulted 2026-10-23

Errori API: tipi, stati e prove

Le note dettagliate di questa edizione sono disponibili in inglese.

Include errors in contract tests

A new type URI, removed extension or changed status may alter consumer behaviour. Failure examples are part of the contract alongside successful responses.

  • Replay existing clients against representative refusals.
  • Check tolerance of unknown extensions and localised text.
  • Document migration of a problem identity and actually observed use.

Explore problem types and eight fictional responses →

IETF · M. Nottingham, E. Wilde, S. Dalal · RFC 9457 · July 2023 · obsoletes RFC 7807 · §3.1, §3.2, §4.2, §5

GraphQL: errori, liste e dati parziali

Le note dettagliate di questa edizione sono disponibili in inglese.

GraphQL API: contract, access and reading experience

Extend API checks with partial-response acceptance cases, field-access tests and a resource budget specific to the service.

  • Compare absent data, partial data and data: null.
  • Keep the original path even when a parent becomes null.
  • Test permissions, quotas and interface states separately.

Explore GraphQL responses and nullability →

GraphQL Specification · September 2025 · Published edition · September 2025

API: deprecazione e ritiro

Le note dettagliate di questa edizione sono disponibili in inglese.

Plan retirement beyond the version number

A published version does not say when consumers need to migrate. Connect deprecation announcements, retirement dates and existing-client tests.

  • Distinguish Deprecation, Sunset and policy links.
  • Check that Sunset does not precede Deprecation when both dates are provided.
  • Measure remaining consumers and validate the replacement before cutover.

Compare deprecation and retirement announcements →

IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23

IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23

Fonti di riferimento

Documenti originali delle organizzazioni responsabili di questi metodi e standard.