Skip to main content
Le proxy est réservé aux clés API HTTP (OpenAI, Stripe, Resend, Anthropic…) : celles qui partent dans un en-tête Authorization ou x-api-key vers une API HTTPS. Les variables non HTTP (DATABASE_URL, JWT_SECRET, REDIS_URL…) restent dans les variables d’environnement de ton hébergeur : Elding ne les stocke pas et ne les injecte pas.

​
Principe

En mode proxy, ton app utilise un placeholder {{NOM_CLE}} pour une clé API HTTP. Le proxy local intercepte chaque requête sortante, remplace le placeholder par la vraie valeur, et forward vers l’upstream.
La vraie clé vit dans le proxy (process séparé), jamais dans la mémoire de ton app.

​
Traitement d’une requête

1

Authentification

Le proxy vérifie le x-elding-token (comparaison constant-time). Seul l’enfant lancé par elding proxy le possède.
2

Anti-SSRF

Le hostname cible est résolu ; toute IP privée, loopback, link-local ou métadata cloud (169.254.169.254) est bloquée. DNS-pinning contre le rebinding.
3

Host-lock

Pour chaque placeholder utilisé, le proxy vérifie que le domaine autorisé de la clé correspond à la cible. Sinon : 403 (anti-exfiltration).
4

Injection & forward

Les placeholders sont substitués dans les en-têtes, la requête est forwardée en streaming (HTTPS uniquement).

​
Sécurité du proxy

  • Bind 127.0.0.1 uniquement, jamais exposé au réseau.
  • Token de session aléatoire, comparaison constant-time.
  • HTTPS only, en-têtes hop-by-hop strippés.
  • Logs sans valeurs (noms de placeholders only).
Une dépendance vérolée ou un agent IA dans ton app ne voit que {{OPENAI_API_KEY}}, jamais la vraie clé.