Serverless rocks, ... but might lead to security headaches for origin server providers because of easiest-to-code (even with ChatGPT) serverless fetch-based proxy attacks!

This page shows the HTTP headers received from an origin server through various serverless plattform fetch requests to detect and potentially prohibit serverless proxies from accessing an origin server.

Infos zu Cdn-Loop: RFC-8586 (initiiert durch Cloudflare!)

Cloudflare erweitert einen Fetch-Request immer (egal ob Worker oder Pages) um folgende Header-Einträge:
Cdn-Loop, Cf-Connecting-Ip, Cf-Ew-Via, Cf-Ray, Cf-Visitor, Cf-Worker

Deno Deploy erweitert einen Fetch-Request nur um folgenden Header-Eintrag:
Cdn-Loop

Amazon AWS Lamdba schickt keinen relevanten Header-Eintrag bei einen Fetch-Request mit, hat aber die Besonderheit, dass explizit ein Request-Header-Eintrag 'Connection: close' eingefügt wird - das kann aber nicht zuverlässig verwertet werden vom Origin Server, weil keine eindeutigen Rückschlüsse auf AWS Lambda dadurch gezogen werden können.

Google Cloud Functions/Run schickt keinen relevanten Header-Eintrag (außer User-Agent) bei einen Fetch-Request mit, hat aber die Besonderheit (Wie AWS Lambda), dass explizit ein Request-Header-Eintrag 'Connection: close' eingefügt wird - das kann aber nicht zuverlässig verwertet werden vom Origin Server, weil keine eindeutigen Rückschlüsse auf Google Cloud Functions dadurch gezogen werden können.

Weitere Cloud Compute Provider konnten nicht detailiert getestet werden, aber es ist davon auszugehen, dass Fastly, Akamai und Envoy Proxy den zusätzlichen Request-Header Cdn-Loop unterstützen und darüber die zuverlässigste Erkennung stattfinden kann! Andere große Anbieter scheinen das aber nicht zu integrieren, also auch nicht DigitalOcean, ScaleWay oder Microsoft Azure, leider. Cloudflare Workers + Pages und Deno Deploy zeichnen sich aus die Unterstützung von Cdn-Loop, obwohl diese Serverless-Dienste keine klassischen CDN (wie Fastly, Akamai oder Envoy Proxy) sind.