Allowlist de IP obligatoria en apps de Shopify: qué hacer antes del 12 y del 20 de noviembre

Si tienes una app pública en la Shopify App Store, esta semana Shopify te puso dos fechas muy cercanas. El 5 de noviembre de 2026 publicó en su changelog que la allowlist de IP pasa a ser obligatoria para todas las apps públicas: el 12 de noviembre se bloquean las bulk operations de las apps que no la tengan, y el 20 de noviembre las que sigan sin ella salen de la App Store y no aceptan instalaciones nuevas.

En este artículo te cuento qué es la allowlist, cómo se configura en el Dev Dashboard (con IPs fijas o, si estás en serverless, con ASN), y los otros cambios de seguridad que llegaron al mismo tiempo: el acceso a bulk operations que hay que habilitar, la sección [network_access] de shopify.app.toml y el calendario de los tokens offline que expiran. Todo sale del changelog y la documentación de shopify.dev consultados el 6 de noviembre de 2026; son fechas y requisitos recientes, así que revísalos en la fuente si lees esto más adelante.

Qué es la allowlist de IP y por qué ahora

Según la documentación, una allowlist de IP limita desde dónde se pueden usar los tokens de acceso de tu app. Con la aplicación activada (enforcement), Shopify revisa la IP de origen de cada petición a la GraphQL Admin API y a la REST Admin API que use tus tokens. Las peticiones desde fuera de la allowlist fallan con un 403, y también las peticiones cuya dirección de origen Shopify no puede confirmar.

La idea es simple: si te roban un token, no sirve de nada fuera de tus servidores. Shopify lo explica así en su anuncio del 5 de noviembre: con las semanas de más actividad del año para los comerciantes a la vuelta de la esquina, lo pide ya. Antes, el 20 de octubre, había publicado “Securing your app, together”, donde contaba que los ataques al ecosistema de apps están aumentando a medida que la IA mejora en encontrar vulnerabilidades, y el 27 de octubre presentó la allowlist como recomendación.

Las fechas que importan

Este es el calendario de la allowlist, tal como aparece en la documentación “Restrict API access with an IP allowlist”:

Las dos primeras fechas vencen a las 11:59 PM ET (hora del Este de EE. UU.), según el changelog. Si estás en México, eso equivale a las 22:59 de Ciudad de México.

A quién afecta: a todas las apps públicas. A quién no: a las custom apps y a las apps que crean los comerciantes en el Dev Dashboard o en el administrador. Aun así, la documentación dice que la allowlist es muy recomendable también para las custom apps.

¿Y si tu app hace llamadas a la Admin API desde la infraestructura del comerciante? El changelog dice que debes moverte lo antes posible a una arquitectura que limite mejor la exposición de los tokens, y que puedes solicitar una extensión de los plazos.

IPs fijas o ASN: cuál usar

La allowlist acepta dos tipos de reglas, y la documentación es clara sobre cuál preferir:

• Si tus IPs de salida son estáticas, añádelas como direcciones IP. Es la allowlist más estrecha, porque solo tus servidores pueden usar tus tokens.
• Si son dinámicas, como en la mayoría de las plataformas serverless, añade los ASN (autonomous system numbers) de tu proveedor de hosting. Esta opción llegó en el changelog del 5 de noviembre.

Reglas para direcciones IP

Se escriben como rangos CIDR (por ejemplo, 203.0.113.0/24 cubre de 203.0.113.0 a 203.0.113.255; una entrada sin prefijo es una sola dirección). Las reglas de la documentación:

• Hasta 100 direcciones o rangos, uno por línea.
• /16 o más estrecho en IPv4 y /32 o más estrecho en IPv6.
• Solo direcciones públicas. Si tus servidores salen por un NAT gateway, usa las direcciones del gateway.
• Cada rango empieza en su dirección de red: 203.0.113.0/24, no 203.0.113.7/24.
• Si tus servidores llegan a Shopify por IPv6, incluye también sus direcciones IPv6.

Reglas para ASN

Aquí va la advertencia más importante de la documentación: la red de un proveedor se comparte con sus otros clientes. Cualquiera que tenga servidores en un ASN que permitas y que tenga un token robado puede usarlo desde ahí. Por eso Shopify recomienda usar solo IPs cuando puedas, y si usas ASN, limitarlos a los países donde corre tu app.

Shopify busca el ASN y el país de la IP de origen en los datos GeoLite de MaxMind. Una petición pasa si su ASN está en tu lista y, si listaste países, si su país también está. Si los datos no tienen ASN para esa dirección (o no tienen país cuando listaste países), la petición se rechaza. Las reglas:

• Hasta 10 ASN, uno por línea, como número con o sin el prefijo AS.
• Solo ASN públicos.
• Hasta 10 países para acotar los ASN. Son opcionales, pero recomendados: sin ellos, el ASN se permite desde cualquier lugar.

Para saber qué ASN usar, la documentación sugiere revisar la documentación de tu proveedor de hosting, o buscar las IPs de cliente de tus peticiones en los Logs de tu app en el Dev Dashboard y comprobar a qué ASN pertenecen. Ojo: un proveedor puede tener varios ASN y añadir más con el tiempo.

Lo que no funciona con allowlist

La documentación avisa de dos casos en los que Shopify no puede confirmar la IP de origen y por eso rechaza la petición:

• Los tokens usados por la acción Send HTTP request de Shopify Flow.
• Los tokens usados para hacer peticiones a la GraphQL Admin API desde una tienda alojada en Oxygen.

Y dos casos que nunca se rechazan: las peticiones de dev preview en tiendas de desarrollo y las peticiones de direct API access desde las páginas embebidas de tu app.

Cómo configurarla paso a paso

Estos son los pasos de la documentación, con los nombres de la interfaz tal cual aparecen:

1. Abre tu app en el Dev Dashboard, haz clic en Settings y luego en Manage en la sección IP allowlist.
2. En Allow requests from, elige IP addresses o Networks (ASN).
3. Escribe lo que quieres permitir:
   • Para IPs, tus direcciones y rangos en IP addresses or CIDR ranges.
   • Para redes, los ASN en Autonomous system numbers (ASNs), y los países donde corre tu app en Countries (recommended).
4. En Test against recent traffic, haz clic en Run test. Revisa si alguna de tus direcciones de los últimos 30 días quedaría bloqueada; si es así, ajusta la allowlist y vuelve a probar. Los resultados pueden tardar unos minutos en incluir tus peticiones más recientes.
5. Activa Enforcement y haz clic en Save.
6. Haz una petición a la GraphQL Admin API desde fuera de tu allowlist y confirma que falla con un 403.

Para dejar de aplicarla, desactiva Enforcement y guarda: Shopify conserva la allowlist para que puedas volver a activarla después.

Mi recomendación: no te saltes el paso 4. Es la forma de descubrir antes del 12 de noviembre ese worker, ese cron o ese entorno de staging que también llama a la Admin API y del que no te acordabas.

Bulk operations: también hay que habilitar el acceso

Si tu app usa bulk operations, el 12 de noviembre no es lo único. Desde el 6 de noviembre de 2026, según el changelog, las apps necesitan acceso a bulk operations antes de poder ejecutar bulk queries o bulk mutations con la GraphQL Admin API. Se habilitan por separado:

• Para bulkOperationRunQuery hace falta acceso a bulk queries.
• Para bulkOperationRunMutation hace falta acceso a bulk mutations.

Si la app lanza una bulk operation sin acceso, la petición devuelve un error de acceso denegado. Aplica a todas las versiones de la GraphQL Admin API y afecta a las apps públicas y a las custom apps que construyes como partner (las que crean los comerciantes no se ven afectadas por ahora).

Si tu app ya ejecutaba bulk operations, Shopify ya le habilitó el acceso. Pero hay un detalle: si tu app no inició una bulk query o una bulk mutation en los últimos 31 días, pierde el acceso a ese tipo y tienes que volver a habilitarlo. Los pasos:

1. En el Partner Dashboard, ve a Apps y selecciona tu app.
2. En la barra lateral, haz clic en API access requests.
3. En Run bulk operations, haz clic en Allow bulk queries, Allow bulk mutations o ambos, según lo que use tu app.

No hace falta cambiar la configuración de la app, publicar una versión nueva ni pedir a los comerciantes que reinstalen: el acceso aplica a todas las tiendas que tienen tu app instalada.

Además, el anuncio del 5 de noviembre adelanta que próximamente las bulk queries y las bulk mutations necesitarán cada una su propio scope. Si tu app ejecutó una bulk operation en los últimos 180 días, Shopify le dará esos scopes automáticamente, pero tendrás que añadirlos a la configuración de tu app antes de tu siguiente deploy. Shopify dice que publicará los nombres de los scopes en el changelog cuando estén listos, así que estate pendiente.

[network_access] en shopify.app.toml

Desde el 27 de octubre, shopify.app.toml tiene una sección nueva, [network_access], donde declaras los hosts y servidores externos que usa tu app. No es obligatoria, pero Shopify la recomienda con fuerza a todas las apps. Tiene dos propiedades:

• allowed_navigation_hosts: los sitios externos a los que tu app manda a los clientes desde la tienda online, por ejemplo tu propio dominio. Normalmente Shopify muestra una advertencia antes de sacar al cliente de la tienda; los enlaces a estos hosts se la saltan. Lista solo hosts que controles, tal como aparecen en tus enlaces, hasta 20.
• allowed_sources: hasta 20 orígenes HTTPS desde los que el código de tu app carga recursos o a los que envía peticiones en la tienda, el checkout y el administrador. Incluye tus extensiones, el app home y las páginas de app proxy. Shopify usa la lista para proteger tu app y detectar peticiones maliciosas.

El ejemplo completo de la documentación, para una app con un bloque de tema, una página de app proxy y una extensión de checkout, queda así:

[network_access]
allowed_navigation_hosts = [
  "app.example.com",
  "help.app.example.com",
]
allowed_sources = [
  "https://api.app.example.com",
  "https://cdn.app.example.com",
]

Dos cosas que no van en la lista, según la documentación: lo que sirve Shopify (como los archivos de la carpeta assets de una theme app extension) y la URL de tu app proxy, porque la tienda sirve esas páginas desde su propio dominio.

Una más, que confunde: si una checkout UI extension necesita llamar a fetch(), además necesita la capability network_access en su propio shopify.extension.toml. Esa capability es independiente de la sección [network_access] de la app.

Probarlo antes de publicar

Desde el 4 de noviembre puedes probar estas listas en una tienda de desarrollo con la feature preview Network access testing:

1. Crea una tienda de desarrollo y selecciona la feature preview Network access testing.

2. Desde el directorio de tu app, corre:

   shopify app dev --store <your-dev-store>.myshopify.com

   Déjalo corriendo mientras pruebas. No instales otras apps en esa tienda: Shopify combina los allowed_sources de todas las apps en una sola política, y la entrada de otra app puede ocultar una que te falte.

3. Añade los bloques de tu theme app extension al tema y activa sus app embeds.

4. Con la consola del navegador abierta, usa cada función de tu app en la tienda online, en su dirección myshopify.com. No pruebes en una vista previa del tema (ni en la vista previa del editor ni en la URL local 127.0.0.1 que imprime Shopify CLI): ahí Shopify no añade la Content Security Policy y la consola no avisa aunque falten servidores.

Si un enlace a uno de tus hosts muestra el aviso de salida, añádelo a allowed_navigation_hosts. Si la consola muestra una advertencia de Content Security Policy para uno de tus servidores, añádelo a allowed_sources. La vista previa solo avisa, no bloquea nada, y la documentación aclara que está en desarrollo y que su comportamiento puede cambiar.

Cuando tengas las listas completas, publica con:

shopify app deploy

Shopify vuelve a validar las dos listas al crear la versión y rechaza el deploy si alguna entrada no cumple las reglas de la referencia de network_access.

El otro plazo: tokens offline que expiran

La allowlist no reemplaza a la otra migración que ya estaba en marcha: las apps públicas deben usar tokens de acceso offline que expiran para la GraphQL Admin API y la REST Admin API. El calendario, actualizado el 27 de octubre:

Shopify insiste en que el 1 de enero es la fecha límite de migración: las fechas posteriores son para que los comerciantes se preparen, no tiempo extra para migrar. No aplica a custom apps, a apps creadas por comerciantes, a tokens online ni a peticiones de la Payments Apps API.

La guía de migración propone tres caminos:

1. Migrar poco a poco: añadir expiring=1 a las peticiones de token que ya haces, y guardar y usar el refresh token que devuelve Shopify. Si tu app usa @shopify/shopify-app-remix o @shopify/shopify-app-react-router, basta con el flag expiringOfflineAccessTokens en future dentro de shopifyApp() y volver a desplegar.
2. Migrar todas las instalaciones de una vez: intercambiar cada token guardado por un par de tokens que expiran mediante token exchange, sin sesión de usuario. Ojo: la migración invalida el token viejo para siempre, así que guarda la respuesta.
3. Usar tokens de acceso solo de aplicación: tu servidor firma una client assertion con una clave privada y obtiene, con el client credentials grant, un token de corta duración (hasta una hora) para cualquier tienda que tenga tu app instalada.

Si tu app está en PHP o Python, los paquetes oficiales que revisé en Apps de Shopify en PHP y Python: los nuevos paquetes oficiales paso a paso traen funciones para el intercambio y la renovación de tokens.

Para encontrar lo que te falte migrar: abre los Logs de tu app en el Dev Dashboard, filtra Type por GraphQL request y Token type por Offline, non-expiring (repite con REST request si usas la REST Admin API). Si aparece alguna petición, todavía estás enviando tokens que no expiran.

La propia documentación de la allowlist recomienda combinar las dos cosas: la allowlist limita desde dónde se puede usar un token filtrado, y los tokens que expiran limitan cuánto tiempo sirve.

Checklist antes del 12 y del 20 de noviembre

• Haz la lista de todo lo que llama a la Admin API con tus tokens: servidor principal, workers, crons, staging.
• Decide IPs o ASN. Si tienes IPs de salida fijas (o un NAT gateway), usa IPs; si estás en serverless, ASN con países.
• Configura la allowlist en Dev Dashboard > Settings > IP allowlist y corre Run test contra el tráfico reciente.
• Activa Enforcement y confirma el 403 desde fuera de la lista.
• Si usas la acción Send HTTP request de Flow con tus tokens, o llamas a la Admin API desde Oxygen, revisa esa arquitectura: la allowlist rechaza esas peticiones.
• Si usas bulk operations, confirma en Partner Dashboard > Apps > API access requests que tienes habilitadas bulk queries y/o bulk mutations, y configura la allowlist antes del 12 de noviembre.
• Declara tus hosts y servidores en [network_access], pruébalos con la feature preview Network access testing y publica con shopify app deploy.
• Revisa en los Logs si todavía envías tokens offline que no expiran y migra antes del 1 de enero de 2027.

Shopify también publicó un hub de seguridad de apps con una página por cada práctica, y en su anuncio del 27 de octubre recomienda correr shopify app security check antes de cada versión. Shopify también sugiere apuntar a tu agente de IA a ese hub para que revise qué prácticas aplican a tu app. Si todavía no conectas tu agente a Shopify, lo expliqué en Shopify AI Toolkit con Claude Code.

Conclusión

La allowlist es un ajuste pequeño en el Dev Dashboard, pero puede tumbar una app si lo haces tarde o a ciegas: un servidor olvidado o una función serverless fuera de la lista y tus peticiones empiezan a devolver 403. Mi recomendación, si tu app es pública: configúrala ya, prueba contra el tráfico reciente antes de activar Enforcement y deja para después lo que no tiene fecha límite, como [network_access]. Y no pierdas de vista el 1 de enero de 2027 para los tokens offline.

Fuentes

• App security updates: IP allowlist is now required (changelog de Shopify, 5 de noviembre de 2026)
• IP allowlists are now required for public apps (changelog de Shopify, 5 de noviembre de 2026)
• App IP allowlists now support apps with serverless hosting through ASNs (changelog de Shopify, 5 de noviembre de 2026)
• Apps must enable bulk operations before use (changelog de Shopify, 6 de noviembre de 2026)
• Test app network access configuration on dev stores (changelog de Shopify, 4 de noviembre de 2026)
• Security update: Offline token dates, new security features (changelog de Shopify, 27 de octubre de 2026)
• Restrict Admin API access with an IP allowlist (changelog de Shopify, 27 de octubre de 2026)
• Secure your app with network access rules in shopify.app.toml (changelog de Shopify, 27 de octubre de 2026)
• Migrate to expiring offline access tokens before January 1, 2027 (changelog de Shopify, 27 de octubre de 2026)
• Securing your app, together (changelog de Shopify, 20 de octubre de 2026)
• Restrict API access with an IP allowlist (documentación de shopify.dev)
• Enabling access to bulk operations (documentación de shopify.dev)
• Declare your app’s network access (documentación de shopify.dev)
• Migrate to expiring offline access tokens (documentación de shopify.dev)
• App security (hub de seguridad de apps en shopify.dev)