E-commerce · Notizia

Shopify impone allowlist IP obbligatorie per le app pubbliche

Shopify richiede alle app pubbliche che chiamano l’Admin API di limitare le reti da cui provengono le richieste. Due scadenze a novembre rendono urgente la migrazione per sviluppatori e merchant.

Schema originale: il traffico API di un’app pubblica viene verificato rispetto a un allowlist di IP o reti di hosting prima di raggiungere Shopify.
Schema originale: il traffico API di un’app pubblica viene verificato rispetto a un allowlist di IP o reti di hosting prima di raggiungere Shopify.Illustrazione originale di CherTra News

Due date, con conseguenze diverse

Shopify ha pubblicato il requisito il 5 novembre 2026. Le app pubbliche che usano le operazioni bulk dell’Admin API devono configurare e attivare un allowlist IP entro il 12 novembre alle 23:59, ora della costa orientale degli Stati Uniti. Dopo quel momento, query e mutation bulk di un’app pubblica non configurata vengono bloccate. Le altre app pubbliche che chiamano l’Admin API hanno tempo fino al 20 novembre alle 23:59 ET: quelle ancora senza allowlist vengono rimosse dall’App Store e non accettano nuove installazioni. Shopify afferma che le installazioni esistenti continueranno a funzionare fino al 1° aprile 2027, quando le richieste Admin API delle app interessate non andranno più a buon fine.

La scadenza del 20 novembre non concede tempo aggiuntivo alle operazioni bulk: per queste vale già il blocco del 12 novembre. Shopify prevede inoltre segnalazioni nelle impostazioni merchant dal 20 novembre e avvisi ai merchant dal 15 gennaio 2027. Sono fasi distinte: il fatto che un’installazione esistente funzioni ancora per un periodo non dimostra che la migrazione sia terminata.

Le app pubbliche rientrano nel requisito, quelle personalizzate no

Il requisito riguarda le app pubbliche, comprese quelle distribuite tramite Shopify App Store. Shopify indica che le app custom e quelle create dai merchant nel Dev Dashboard o nell’admin non sono interessate da questo specifico obbligo rivolto alle app pubbliche. Ciò non rende un’app personalizzata immune ai rischi delle credenziali: quando la piattaforma lo consente, limitare le reti autorizzate può comunque ridurre l’utilità di un token esposto.

Chi usa un’app dovrebbe chiedere al fornitore se questa chiama l’Admin API, se esegue operazioni bulk e se l’allowlist è già attiva. In genere il merchant non può fornire al posto dello sviluppatore gli indirizzi di uscita della sua applicazione. La responsabilità è dell’autore dell’app, anche se il merchant potrebbe dover testare i propri flussi dopo una modifica di hosting o rete.

Indirizzi statici e reti serverless

Le app con IP di uscita stabili possono inserire nel Dev Dashboard gli indirizzi o i relativi intervalli CIDR. Un servizio serverless può invece uscire da indirizzi variabili, rendendo fragile un elenco di singoli IP. L’aggiornamento Shopify del 5 novembre aggiunge l’opzione Networks: lo sviluppatore può autorizzare gli autonomous system number (ASN) del provider, restringere i Paesi ammessi, verificare la scelta sul traffico recente e poi attivare l’applicazione della regola. Shopify documenta un massimo di dieci ASN e dieci Paesi; le richieste provenienti da reti esterne ricevono HTTP 403.

Le regole ASN coprono reti più ampie di un singolo indirizzo e richiedono quindi una scelta accurata di provider e geografia. Non giustificano l’autorizzazione di qualunque provider o Paese. Prima dell’attivazione, occorre includere le regioni di produzione e i processi in background legittimi e verificare il traffico recente. La documentazione Shopify indirizza i team con egress dinamico verso gli ASN, non verso indirizzi indovinati.

Checklist di migrazione per gli sviluppatori

Per prima cosa, censire tutte le app pubbliche, le integrazioni Admin API, i worker in background e le operazioni bulk. Registrare il percorso di uscita di rete di ogni ambiente, senza confondere sviluppo e anteprima con la produzione. Poi scegliere IP/CIDR statici oppure una regola ASN e Paesi circoscritta, in base all’architettura effettiva. Verificare la regola sul traffico recente, provare i normali flussi e le operazioni bulk, quindi attivare l’enforcement.

Dopo il rilascio, monitorare le risposte 403 e gli errori API, aggiornare l’allowlist quando cambia l’infrastruttura e assegnare un responsabile delle modifiche future. Preparare e testare una procedura di ripristino prima della scadenza, invece di aspettare il primo errore in produzione. I merchant dovrebbero contattare per tempo i fornitori delle app e pianificare un controllo successivo di ordini, inventario e funzioni operative essenziali.

Fonti e approfondimenti

Vuoi segnalare un errore o suggerire una fonte? Contatta la redazione.