Die CGI-Schnittstelle (Common Gateway Interface – in etwa Allgemeine Vermittlungsrechner-Schnittstelle) ist ein Standard im Web für den Datenaustausch zwischen auf Webservern bereitstehenden Programmen (Scripts) und den sie aufrufenden Webbrowsern. Hierbei können die serverseitigen Programme, die z.B. von HTML-Dateien aus aufgerufen werden können, sowohl Daten vom Browser empfangen (etwa Formulareinträge) als auch neu generierte Daten an den Browser verschicken (etwa eine HTML-Seite). CGI ist also eine schon länger bestehende Variante, Webseiten dynamisch bzw. interaktiv zu machen.

Um die CGI-Schnittstelle zu verwenden, muss diese von der Webserver-Software unterstützt werden. Dabei ist wichtig, dass diese Software dem Programm/Script immer 3 Dinge zur Verfügung stellt:

• Umgebungsvariablen (z.B. SERVER_NAME), deren Inhalte dem Programm helfen, sich „vor Ort“ zu orientieren und über aktuelle Einstellungen zu informieren.

• Weiterleitung von Ausgaben, meistens als dynamisch erzeugte HTML-Seite (oder Seitenteile), aber auch als Einträge in Fehlerprotokolldateien.

• Einholen von Formulareingaben oder Aufrufparametern z.B. aus HTML-Seiten, damit das CGI-Programm/-Script auf diese reagieren kann. Dabei können solche Daten als Umgebungsvariable (GET-Methode) oder über einen Eingabe-Kanal (POST-Methode) Eingang ins Programm/Script finden, wobei letztere Möglichkeit sicherer ist.

Wie diese Daten strukturiert sind, ist die eigentliche Schnittstellenbeschreibung (deshalb „interface“).

CGI-Programme können also in allen möglichen Programmiersprachen geschrieben sein. Es muss lediglich auf dem Server ein entsprechender Laufzeitinterpreter vorhanden sein, oder das Programm muss für das Serverbetriebssystem kompiliert worden sein. Am weitesten verbreitet ist hierbei Perl.

Ein Nachteil, der der CGI-Ausführung nachgesagt wird, ist, dass sie langsamer sei als andere Möglichkeiten (z.B. Servlets), da für jeden CGI-Aufruf eine neue Programm-Instanz ausgeführt werden muss. Deshalb wird CGI heutzutage nicht mehr so oft eingesetzt, denn selbst Ansätze wie FastCGI, welches gewisse Nachteile von CGI aufhebt, konnten sich zumindest nicht auf breiter Front durchsetzen. Andererseits wird dieser Nachteil von modernen Webserver-Typen für einige Programmiersprachen behoben (z.B. bietet der Webserver Apache mit dem Modul mod_perl die Möglichkeit, einen Perl-Interpreter in den Webserver selbst einzubetten, was – neben anderen Vorteilen – die Ausführungsgeschwindigkeit massiv erhöhen kann). Alle derartigen Lösungen sind jedoch nicht mehr programmiersprachenunabhängig.

Die Tatsache, dass über CGI auf dem Webserver eines kommerziellen Providers Programme ausgeführt werden können, die ein Kunde des Providers selbst erstellt hat, ist in höchstem Maße sicherheitsrelevant. Daher muss sichergestellt sein, dass ein über CGI gestartetes Programm nur bestimmte eingeschränkte Typen von Programmroutinen ausführen darf (z.B. kein Löschen von Dateien des Webservers u.ä.). Bei dem Apache-Webserver wird die Ausführung von CGI-Programmen mit Hilfe des Modules suexec gegen solche Cracker-Angriffe gesichert, die das Eindringen als Root-User zum Ziel haben. Die Sicherheitsmaßnahmen sind dabei mehrstufig aufgebaut und so streng, dass viele Server-Administratoren dazu übergegangen sind, auch andere serverseitige Sprachen über CGI laufen zu lassen. So wird zum Beispiel PHP bei den meisten Providern als CGI-Modul eingebunden (mit dem Nachteil, dass es alle Vorteile in Bezug auf den oben genannten Geschwindigkeitsgewinn verliert).