Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Un pare-feu détermine quel trafic réseau est autorisé à passer et quel trafic est refusé. Les pare-feu peuvent s'appliquer au trafic entrant (entrée), au trafic sortant (sortie) ou aux deux. Pour App Engine, le pare-feu App Engine ne s'applique qu'au trafic entrant acheminé vers votre application ou votre service.
Présentation
Le pare-feu App Engine est vérifié pour tous les types de requêtes adressées à votre application, y compris :
Le trafic Web standard est acheminé vers l'adresse appspot.com ou le domaine personnalisé de l'application.
Trafic provenant de sources internes telles que les machines virtuelles (VM) Compute Engine et Cloud Tasks.
Si votre application est configurée pour utiliser d'autres services ou produits de mise en réseau, vous devrez peut-être créer des règles pour contrôler le trafic entrant à la fois dans le pare-feu App Engine et dans les paramètres de pare-feu ou de sécurité d'autres produits. Ce guide couvre le comportement général du pare-feu App Engine et fournit des informations sur ces cas d'utilisation spécifiques.
Règles de pare-feu App Engine
Vous pouvez configurer des règles de pare-feu App Engine à l'aide de la console Google Cloud, de Google Cloud CLI ou de l'API Admin en spécifiant des règles qui autorisent ou bloquent les plages d'adresses IP spécifiées.
Par défaut, toute requête qui ne correspond pas à une règle est autorisée à accéder à votre application. Si vous devez bloquer toutes les requêtes qui ne correspondent pas à une règle spécifique (à l'exception des requêtes des services internes autorisées par défaut), remplacez l'action de la règle default par deny.
Fonctionnalité de pare-feu
Dans l'environnement standard App Engine, le pare-feu App Engine peut autoriser un certain trafic interne à contourner le pare-feu. Cela signifie que si vous définissez la règle default sur deny, les requêtes de certains services destinés à l'environnement standard App Engine ne sont pas bloquées. Ce sont tous des types de trafic demandés dans la configuration de l'application ou envoyés à partir de la même application. Les requêtes qui contournent les règles de pare-feu de cette manière incluent :
Pour les applications qui utilisent l'environnement standard App Engine et les services fournis avec les environnements d'exécution de première génération, les notifications de l'ancienne API Mail contournent également le pare-feu.
Autoriser les requêtes entrantes de vos services
Le tableau suivant répertorie les plages d'adresses IP et le comportement du pare-feu App Engine pour les services courants. La plage d'adresses IP que vous utilisez varie selon que les requêtes entrantes sont transmises à une version qui s'exécute dans l'environnement standard ou flexible d'App Engine.
Service
Plage d'adresses IP pour les requêtes envoyées à l'environnement standard App Engine
Plage d'adresses IP pour les requêtes envoyées à l'environnement flexible App Engine
Cloud Storage ou Blobstore
0.1.0.30/32
Non applicable
Tâches Cloud Scheduler utilisant des tâches HTTP App Engine et App Engine dans Cloud Tasks (y compris les files d'attente de tâches App Engine)
0.1.0.2/32, contourne la règle de pare-feu par défaut si elle est définie sur "Refuser"
0.1.0.2/32
Cron App Engine
0.1.0.1/32 ou 0.1.0.2/32, contourne la règle de pare-feu par défaut si elle est définie sur "Refuser"
Selon votre cas d'utilisation, ces instructions supplémentaires peuvent s'appliquer lors de la configuration des règles de pare-feu App Engine :
Les requêtes provenant de tâches Cron App Engine nouvellement créées ou mises à jour et envoyées à l'environnement standard ou flexible App Engine proviennent de 0.1.0.2. Pour les tâches Cron créées avec des versions anciennes de gcloud (antérieures à la version 326.0.0), les requêtes Cron proviennent de 0.1.0.1. Pour en savoir plus sur l'identification des requêtes du service Cron d'App Engine, consultez la page Valider des requêtes Cron.
Votre application s'exécutant dans l'environnement standard comporte deux services : frontend_service et backend_service. frontend_service utilise Cloud Tasks avec le protocole HTTP d'App Engine pour envoyer des messages à backend_service. Étant donné que la règle de pare-feu default autorise les requêtes Cloud Tasks, même si elle est configurée sur deny, vous n'avez pas besoin de créer une règle de pare-feu pour Cloud Tasks.
Toutefois, si vous souhaitez limiter l'accès à votre application et bloquer explicitement les requêtes Cloud Tasks, vous devez créer une règle de pare-feu deny pour la plage d'adresses IP 0.1.0.2/32.
Exemple d'environnement flexible App Engine
Votre application s'exécutant dans l'environnement flexible comporte deux services : frontend_service et backend_service, et dispose d'un pare-feu configuré pour refuser le trafic par défaut. frontend_service utilise Cloud Tasks avec le protocole HTTP d'App Engine pour envoyer des messages à backend_service. Étant donné que la règle de pare-feu default refuse les requêtes Cloud Tasks, vous devez créer une règle de pare-feu allow pour 0.1.0.2/32.
L'équilibreur de charge n'interfère pas avec les règles de pare-feu App Engine et n'interagit pas avec elles. Les règles de pare-feu App Engine ne sont évaluées que lorsqu'un NEG sans serveur dirige le trafic vers App Engine.
Nous vous recommandons d'utiliser des contrôles d'entrée afin que votre application ne reçoive que les requêtes envoyées par l'équilibreur de charge (et par le VPC le cas échéant). Sinon, les utilisateurs peuvent se servir de l'URL App Engine de votre application pour contourner l'équilibreur de charge, les règles de sécurité Google Cloud Armor, les certificats SSL et les clés privées qui sont transmises via l'équilibreur de charge.
Le pare-feu App Engine repose sur des mécanismes qui mettent en cache le contenu (tels que des serveurs proxy et des navigateurs Web). Lorsque du contenu est mis en cache, il est diffusé publiquement à partir de l'URL concernée jusqu'à son expiration. Il est possible d'y accéder même après la création d'autres règles de pare-feu.
Pour savoir comment modifier le délai d'expiration par défaut du contenu statique ou empêcher la mise en cache du contenu statique, consultez Expiration du cache.
Pour empêcher la mise en cache du contenu dynamique de sortie du code de votre application, utilisez les en-têtes de réponse HTTP Cache-Control et Expires. Pour en savoir plus sur ces en-têtes HTTP, y compris sur le contrôle de la mise en cache, consultez Éviter la mise en cache.
Étape suivante
Suivez les instructions de la page Créer des pare-feu pour apprendre à configurer des règles de pare-feu App Engine.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/04/21 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/04/21 (UTC)."],[[["\u003cp\u003eThe App Engine firewall controls incoming traffic to your app, allowing or blocking requests based on specified IP ranges.\u003c/p\u003e\n"],["\u003cp\u003eBy default, requests not matching any defined rule are allowed, but this can be changed to deny access unless specifically allowed.\u003c/p\u003e\n"],["\u003cp\u003eCertain internal traffic, like warmup requests and Cloud Tasks, can bypass the firewall rules even when the default action is set to deny in the App Engine standard environment.\u003c/p\u003e\n"],["\u003cp\u003eWhen using Cloud Load Balancing, the App Engine firewall does not interact with the load balancer, and it is recommended to use ingress controls to ensure that requests only come through the load balancer.\u003c/p\u003e\n"],["\u003cp\u003eCached content may still be accessible publicly, even after new firewall rules are put in place, so control the cache behavior of static and dynamic content using Cache-Control and Expires headers.\u003c/p\u003e\n"]]],[],null,["# Understanding the App Engine firewall\n\nA **firewall** determines which network traffic is allowed to pass and which\ntraffic is rejected. Firewalls can apply to incoming traffic (ingress), outgoing\ntraffic (egress), or both. For App Engine, the App Engine firewall only\napplies to incoming traffic routed to your app or service.\n\nOverview\n--------\n\nThe App Engine firewall is checked for all types of\nrequests to your app, including:\n\n- Regular web traffic routed to the app's `appspot.com` address or custom domain.\n- Requests that arrive from [Cloud Load Balancing](/load-balancing).\n- Traffic from internal sources such as Compute Engine virtual machines (VMs) and Cloud Tasks.\n\nIn cases where your app is configured to use other networking services or\nproducts, you might need to create rules for controlling incoming traffic in\nboth the App Engine firewall and the firewall or security settings of other\nproducts. This guide covers the general behavior of the App Engine firewall,\nand details about those special use cases.\n\nApp Engine firewall rules\n-------------------------\n\nYou can [configure App Engine firewall rules](/appengine/docs/legacy/standard/python/creating-firewalls)\nusing the Google Cloud console, the Google Cloud CLI, or the Admin\nAPI by specifying rules that allow or block specified IP ranges.\n\nBy default, any request that does not match a rule is allowed access to your\napp. If you need to block all requests that do not match a specific rule\n(excluding requests from internal services allowed by default), change the\n`default` rule's action to `deny`.\n\n### Firewall feature\n\nIn the App Engine standard environment, the App Engine firewall can allow certain internal\ntraffic to bypass the firewall. This means that if you set the `default` rule to\n`deny`, requests from certain services destined for the App Engine standard environment do not\nget blocked. These are all types of traffic requested in the app's own\nconfiguration, or sent from the same app. Requests that bypass firewall rules in\nthis way include:\n\n- [Warmup requests](/appengine/docs/legacy/standard/python/configuring-warmup-requests)\n- Cloud Scheduler jobs using [App Engine HTTP](/scheduler/docs/creating#creating_jobs) (including [App Engine Cron](/appengine/docs/legacy/standard/python/config/cron)\n\n \u003cbr /\u003e\n\n - [App Engine tasks in Cloud Tasks](/tasks/docs/creating-appengine-tasks) (including App Engine Task Queues)\n\n For apps that use the App Engine standard environment and services bundled with the [first\n generation runtimes](/appengine/docs/standard/runtimes), notifications from the\n legacy Mail API also bypass the firewall.\n\n Allowing incoming requests from your services\n ---------------------------------------------\n\n The following table lists the IP ranges and App Engine firewall behavior for\n common services. The IP range you use depends on whether the incoming requests\n are delivered to a version that runs on the App Engine standard environment or\n flexible environment.\n\n Depending on your use case, these additional instructions might apply when\n configuring App Engine firewall rules:\n - Requests from newly created or updated App Engine Cron jobs sent to either the App Engine standard or flexible environment come from `0.1.0.2`. For Cron jobs created with older gcloud versions (earlier than 326.0.0), Cron requests will come from `0.1.0.1`. To learn more about how to identify requests from the App Engine Cron service, see [Validating cron requests](/appengine/docs/legacy/standard/python/scheduling-jobs-with-cron-yaml#validating_cron_requests).\n - If your app interacts with Cloud Load Balancing or is connected to a VPC network, see the [Interaction with other products or services](#interaction_with_other_products_or_services) section below.\n\n | **Caution:** Creating a rule for IP `0.0.0.0` will apply to **all** Compute Engine instances with Private Google Access enabled, not only the ones you own. Similarly, allowing requests from `0.1.0.40` will allow **any** App Engine app to make URL Fetch requests to your app.\n\n ### App Engine standard example\n\n Your app running in the standard environment has two services: `frontend_service`\n and `backend_service`. `frontend_service` uses Cloud Tasks with\n App Engine HTTP to send messages to `backend_service`. Since the `default`\n firewall rule allows Cloud Tasks requests even if configured to `deny`, you do not need to create\n a firewall rule for Cloud Tasks.\n\n However, if you wanted to restrict access to your app and explicitly block\n Cloud Tasks requests, you would create a `deny` firewall rule for IP range `0.1.0.2/32`.\n\n ### App Engine flexible example\n\n Your app running in the flexible environment has two services:\n `frontend_service` and `backend_service`, and has a firewall configured to deny\n traffic by default. `frontend_service` uses Cloud Tasks with\n App Engine HTTP to send messages to `backend_service`. Since the `default`\n firewall rule denies Cloud Tasks requests, you would need to create an\n `allow` firewall rule for `0.1.0.2/32`.\n\n Interaction with other products or services\n -------------------------------------------\n\n ### Cloud Load Balancing\n\n If you use [Cloud Load Balancing and serverless NEGs](/load-balancing/docs/negs/serverless-neg-concepts), note the following:\n - The load balancer does not interfere or interact with App Engine firewall rules. The App Engine firewall rules are not evaluated until a serverless NEG directs traffic to App Engine.\n\n \u003c!-- --\u003e\n\n - We recommend that you [use ingress controls](/appengine/docs/standard/application-security#ingress_controls)\n so that your app only receives requests sent from the load balancer\n (and the VPC if you use it). Otherwise, users can use your app's\n App Engine URL to bypass the load balancer, Cloud Armor\n security policies, SSL certificates, and private keys that are passed through\n the load balancer.\n\n - If your [ingress controls](/appengine/docs/legacy/standard/python/application-security#ingress_controls) are set to receive `internal-and-cloud-load-balancing` traffic, leave the default App Engine firewall rule as is (`allow`), and use [Google Cloud Armor web application firewall (WAF) rules](/armor/docs/rule-tuning).\n\n Preventing access to cached content\n -----------------------------------\n\n The App Engine firewall sits behind mechanisms that cache content, for example\n web proxies and browsers. When content is cached, that content is served\n publicly from the specific URL until it expires and can be accessed even after\n creating new firewall rules.\n For information about changing the default expiration time for static content or preventing static content from being cached, see [Cache expiration](/appengine/docs/legacy/standard/python/how-requests-are-handled#static_cache_expiration).\n\n \u003cbr /\u003e\n\n To prevent dynamic content output from your app's code from being cached, use\n the `Cache-Control` and `Expires` HTTP response headers. For more information about\n these HTTP headers, including how to control caching, see\n [Avoiding caching](https://wikipedia.org/wiki/List_of_HTTP_header_fields#Avoiding_caching).\n\n\n What's next\n -----------\n\n Follow the instructions in [Creating\n Firewalls](/appengine/docs/legacy/standard/python/creating-firewalls) to\n learn how to configure App Engine firewall rules."]]
