Die Abkürzung CGI ist bekannt unter der Bezeichnung Common Gateway Interface und beschreibt einen Standard zum Datenaustausch zwischen Software von Drittanbietern und einem Webserver. Anfragen, die diese Software an den Webserver stellt, werden dynamisch und interaktiv durchgeführt. Die ersten Überlegungen zu diesem CGI-Standard gehen auf das Jahr 1993 zurück.

CGI (Common Gateway Interface) dient als klar definierte Schnittstelle, über die ein Webserver externe Programme startet, Eingaben übergibt und Ausgaben entgegennimmt. Typische Einsatzfälle sind die Verarbeitung von Webformularen, Suchabfragen, Bild- oder PDF-Generierung sowie das Bereitstellen dynamischer Inhalte, die bei der HTTP-Anfrage erst erzeugt werden. Die Spezifikation wurde als CGI/1.1 (RFC 3875) formalisiert; frühe Skizzen und Implementierungen stammen aus den frühen 1990ern. Während CGI historisch ist, bleibt das Konzept als Grundlage vieler moderner Architekturen relevant.

Funktionsweise der CGI-Schnittstelle

Zunächst muss auch der Webserver CGI unterstützen. Er stellt dabei einer Websoftware eine Laufzeitumgebung zur Verfügung, die aus Umgebungsvariablen und Ein- und Ausgabekanälen besteht. Eine Umgebungsvariable stellt beispielsweise den Servernamen dar. Die Variablen helfen dem Anwenderprogramm eine Anfrage an den Webserver zu stellen und dessen Situation darzulegen.

Das Format ist größtenteils standardisiert. Über die Ein- und Ausgabekanäle werden die jeweiligen Datenströme bereitgestellt. Korrekt ist dabei: Der Webserver liefert dem CGI-Programm bei POST/PUT den Request-Body über stdin, während das CGI-Programm seine Antwort (Header und Body) über stdout an den Webserver zurückgibt. Der große Vorteil des CGI ist es, HTML-Webseiten dynamisch zu erzeugen.

Früher wurden die meisten Webseiten statisch wiedergegeben, die eine Interaktion mit dem Server nicht einfach machte. Dynamische Webinhalte müssen während der Anfrage noch nicht auf dem Server vorhanden sein. Sie werden über das CGI-Script erst erzeugt. Generell gibt es viele Programmiersprachen, die CGI unterstützen.

Ablauf eines CGI-Requests in Schritten:

1. Browser sendet eine HTTP-Anfrage (GET/POST/…) an den Webserver.
2. Der Webserver erkennt anhand der Konfiguration (z. B. Dateiendung, Pfad, Handler), dass ein CGI-Programm auszuführen ist.
3. Der Server setzt definierte Umgebungsvariablen (z. B. REQUEST_METHOD, QUERY_STRING, CONTENT_TYPE, CONTENT_LENGTH, PATH_INFO, REMOTE_ADDR, SERVER_SOFTWARE, GATEWAY_INTERFACE) und startet das Programm als eigenen Prozess.
4. Bei POST/PUT stellt der Server den Request-Body über stdin bereit; GET-Parameter werden in QUERY_STRING übergeben.
5. Das CGI-Programm erzeugt die Ausgabe (inkl. HTTP-ähnlicher Header wie Content-Type) auf stdout, die der Webserver in eine HTTP-Antwort umwandelt und an den Client sendet.

• CGI/1.1 (aktuell in der Praxis): Festgelegt in RFC 3875, breite Unterstützung in gängigen HTTP-Servern.
• Frühere Entwürfe (historisch): Frühe Versionen und Entwürfe legten die Basis für die heute stabile Implementierung, sind aber selten mehr im produktiven Einsatz.

Wichtige Details: CGI ist sprachagnostisch. Ob Shell, Perl, Python, C/C++, Ruby oder andere – entscheidend ist die Einhaltung des Protokolls (Header plus Body auf stdout, Einlese-Mechanismen über stdin und Umgebungsvariablen). Die Trennung von Programm und Webserverprozess sorgt für eine klare Isolation, aber auch für Verwaltungs- und Startkosten je Aufruf.

Nachteile des CGI

Für jeden CGI-Aufruf muss immer ein neuer Prozess gestartet werden. Daher sind CGI-Ausführungen relativ langsam. Auf vielbesuchten Internetpräsenzen wird CGI heute nicht mehr so oft verwendet. Auch das nachfolgende FastCGI konnte sich nicht durchsetzen. Stattdessen wurden entsprechende Module entwickelt, in denen verschiedene Scriptsprachen verwendet werden und den Interpreter direkt in den Prozess des Webservers einbinden.

So gibt es beispielsweise für den Apache-Webserver die Module mod_per für die Sprache Perl oder mod_python für die Sprache Python. Die Module werden nur einmal beim Starten des Webservers geladen und nicht wie bisher vor jeder einzelnen Anfrage. Eine effiziente Möglichkeit ist auch, die Webprogramme als externe Prozesse zu starten. Diese können dann über FastCGI die jeweiligen Requests des Browsers übergeben. Bei dieser Methode können der Interpreter der Programmiersprache und die Webanwendung selbst die ganze Zeit über geladen sein. Auf diese Weise können Anfragen sehr effektiv bearbeitet werden.

Aktualisierte Einordnung (historische Info beibehalten): Das klassische CGI skaliert schlecht unter hoher Last, da Prozessstart und -ende pro Anfrage Ressourcen kosten (CPU, I/O, Kontextwechsel). Heutige Systeme nutzen daher häufig persistente Ansätze:

• FastCGI (heute breit etabliert, z. B. via PHP-FPM, auch hinter Apache und Nginx): Der Interpreter läuft dauerhaft, Anfragen werden über Sockets weitergereicht. Das reduziert Start-Overhead drastisch.
• Server-Module wie mod_perl (korrekt so benannt) oder moderne Alternativen zu mod_python wie mod_wsgi für Python: Interpreter wird im Serverprozess eingebunden, was Latenzen minimiert. Hinweis: mod_python gilt als überholt; heute ist WSGI/mod_wsgi der Standardansatz für Python.
• Application-Server (z. B. Servlet-Container) oder Protokolle wie SCGI/uWSGI: Entkoppeln Anwendungslogik vom Webserver, halten Prozesse warm und ermöglichen horizontale Skalierung.

Zusätzliche Nachteile von klassischem CGI:

• Zustandslosigkeit pro Prozessstart erschwert Caching und Session-Management direkt im Prozess.
• Höherer Ressourcenbedarf pro Request (Speicher, Dateideskriptoren), limitierte Parallelisierbarkeit.
• Komplexere Fehleranalyse (Prozessprotokolle) und potenziell längere Kaltstartzeiten.

Ist CGI sicher?

Verständlicherweise sind Drittprogramme, also Webanwendungen, die ein Dritter programmiert hat und die auf einem Webserver ausgeführt werden, immer sicherheitsrelevant anzusehen. Von daher muss generell sichergestellt sein, dass ein Programm, welches CGI-Routinen verwendet, nur erlaubte Typen von Programmroutinen ausführt. So darf beispielsweise das Programm nicht unerlaubter Weise Dateien vom Webserver löschen oder kopieren.

Über das Modul suexec schützt sich beispielsweise der Apache-Server vor unerlaubter Ausführung von Cracker-Programmen. Dabei sind die jeweiligen Sicherheitsmechanismen oftmals mehrstufig aufgebaut. Die Sicherheit ist dabei so effizient, dass etliche Administratoren dazu übergegangen sind, auch andere Server-Sprachen über CGI zu starten.

Empfohlene Sicherheitsmaßnahmen bei CGI:

• Eingabevalidierung: Strikte Prüfung und Whitelisting von Parametern; Vermeidung von Shell-Injection, Command-Injection und Directory-Traversal.
• Rechte- und Nutzertrennung: Ausführung unter dedizierten, minimal privilegierten Accounts (suexec/similar), keinerlei setuid-Programme ohne Notwendigkeit.
• Umgebungsvariablen härten: Definierte, bereinigte Umgebungen (PATH, LANG, LC_*, TZ) setzen; keine Abhängigkeit von unkontrollierten Variablen.
• Datei- und Pfadkontrollen: Temp-Verzeichnisse absichern, Race-Conditions (TOCTOU) vermeiden, restriktive Berechtigungen verwenden.
• Fehlerausgaben begrenzen: Keine internen Pfade oder Stacktraces an Clients preisgeben; Logging zentralisieren.
• Transportabsicherung: Kommunikation über verschlüsselte Verbindungen bereitstellen; Sitzungsdaten schützen.

Alternativen zu CGI

Neben CGI werden häufig als serverseitige Technologien FastCGI, Servlet, PHP, ColdFusion, Active Server Pages (ASP) und Server Side Includes (SSI) verwendet. Viele Internetprovider stellen ihren Nutzern entsprechende CGI-Scripte zur Verfügung. Ein beliebtes Script ist beispielsweise der Besuchszähler.

Moderne Alternativen und Einordnung:

• FastCGI: Dauerhafte Prozesse, sehr gute Performance; in der Praxis weit verbreitet (u. a. über Prozessmanager wie FPM).
• Servlet-Container: Java-basierte Umgebungen (z. B. für Servlets/JSP) mit Threading und Session-Management.
• PHP als Modul oder über Prozessmanager: Interpreter persistent geladen (mod_php) oder als schneller externer Dienst (FPM/Proxy).
• WSGI/ASGI für Python: Standardisierte Gateways für synchrone und asynchrone Anwendungen (mod_wsgi, uWSGI, Gunicorn/uvicorn hinter einem Proxy).
• SSI: Serverseitige Includes für einfache dynamische Einbindungen, leichtgewichtig, aber funktional begrenzt.

Wann CGI weiterhin sinnvoll sein kann:

• Kleine, isolierte Hilfsprogramme ohne hohen Traffic.
• Umgebungen mit starker Prozessisolation als Sicherheitsmaßnahme.
• Legacy-Systeme, bei denen ein schneller Umbau auf persistent laufende Stacks nicht möglich ist.

Häufige Fragen und Antworten