Un WAF et une limite de débit sans fournisseur d'edge séparé

Une bonne partie de ce que vend un fournisseur d’edge/WAF dédié est en fait simplement un proxy inverse qui fait correctement son travail : vérifier la requête avant qu’elle n’atteigne l’application, pas après. Railyard fait déjà tourner un proxy web devant les applications de chaque serveur — ce sont les règles qui s’exécutent là, la plupart configurables depuis l’onglet Settings → Networking de l’application, sans relation avec un fournisseur séparé.

Ce qui est en direct aujourd’hui, sans réserve

• Mot de passe et règles IP. Mettez un mot de passe sur un staging ou un outil admin en un champ; autorisez ou refusez des adresses ou plages CIDR spécifiques, tout le reste recevant un 403 propre.
• Redirections et réécritures — jusqu’à 100 règles, vérifiées dans l’ordre, la première correspondance l’emporte. 301/302/307/308 ou une rewrite vers la même application qui garde la chaîne de requête. Désactivées en mode maintenance, pour qu’une règle de redirection ne masque jamais une vraie panne.
• En-têtes de réponse et CORS, jusqu’à 50 règles. Définissez un en-tête, ou retirez-en un que votre application a envoyé avec -Name. Les préflights CORS sont répondus par le proxy lui-même et n’atteignent jamais l’application — ce qui veut aussi dire qu’une application protégée par mot de passe répond correctement aux préflights avec 401 plutôt que de laisser fuiter une réponse CORS d’abord.
• Votre propre certificat SSL. Collez un certificat et une clé PEM; Railyard vérifie que la clé correspond au certificat, que le certificat est valide maintenant, et qu’il couvre vraiment une des adresses de l’application — avant l’enregistrement, pas après qu’une chose casse. Stocké chiffré, jamais retourné par l’API, et volontairement exclu de railyard.yml pour qu’une clé privée ne finisse jamais dans git.
• Pages d’erreur et de maintenance, servies avec le vrai code de statut (502/503/504) au lieu d’un échec générique vide.

Ce qui est réel mais encore en déploiement — dit honnêtement

Trois fonctionnalités existent et sont entièrement configurables aujourd’hui, mais ont besoin de la propre image de proxy edge de Railyard sur un serveur, encore en cours de déploiement sur toute la flotte. Tant qu’un serveur donné ne l’a pas, la règle est enregistrée mais pas appliquée, et la carte de réglages comme le journal de déploiement le disent clairement — rien ne prétend être actif quand ça ne l’est pas :

• Pare-feu applicatif web (WAF) — chaque requête vérifiée contre l’OWASP Core Rule Set (injection SQL, XSS, les autres catégories CRS standards) avant d’atteindre l’application. Trois modes : désactivé, détection (journalisé, ne bloque jamais — la bonne première étape pour voir ce qui aurait été bloqué avant d’activer l’application), et blocage (appliqué, retourne 403).
• Limitation de débit — requêtes par minute par IP cliente, réglable pour toute l’application et par chemin (/login 10, /api/* 120). Au-delà de la limite, 429 avec Retry-After. Une vraie limite à connaître : les compteurs vivent dans la mémoire propre de chaque serveur, donc une application répartie sur plusieurs serveurs a la limite par serveur, pas un total global — et derrière Cloudflare ou un autre proxy, chaque visiteur ressemble actuellement à l’IP de ce proxy.
• Blocage par pays — listes d’autorisation/blocage de codes pays à deux lettres, UNK pour les adresses sans pays connu, vérifié avant les limites de débit, les redirections, ou l’application elle-même. Les adresses privées et internes passent toujours, peu importe.

Pourquoi l’honnêteté compte ici en particulier

Un WAF qui n’applique rien silencieusement est pire que pas de WAF du tout, parce que ça crée une fausse confiance — la seule chose que cette catégorie de fonctionnalité ne peut pas se permettre de rater. Dire clairement « enregistré mais pas encore appliqué » dans le produit lui-même, pas seulement dans un changelog, est la vraie protection contre ça, et ça mérite d’être dit ici aussi plutôt que de laisser croire que tout ce qui précède est uniformément en direct.

Référence complète : Règles edge.