GET-Parameter verstehen und sicher in URLs nutzen

Eine URL wie /produkte?category=laptop&sort=price sieht unscheinbar aus, steuert aber oft die komplette Darstellung einer Seite. Der englische Ausdruck get parameter beschreibt Werte, die über die URL an eine Webanwendung übergeben werden. Ich zeige, wie diese Parameter aufgebaut sind, wie JavaScript und gängige Frameworks sie auslesen und warum Validierung, Datenschutz und korrektes Encoding entscheidend sind.

Was GET-Parameter in einer URL tatsächlich leisten

Ein GET-Parameter ist ein benanntes Wertepaar in der sogenannten Query-String-Komponente einer URL. Sie beginnt mit ?, etwa in /suche?q=webentwicklung. Der Name lautet hier q, der übergebene Wert webentwicklung.

Mehrere Werte werden normalerweise mit & getrennt. Die URL /artikel?topic=ai&page=2 übergibt also die Parameter topic und page. Der Browser sendet diese Informationen bei einem HTTP-GET-Aufruf an den Server, der daraus beispielsweise eine gefilterte Ergebnisliste erzeugt.

In der Praxis nutze ich diese Technik vor allem für Zustände, die sich problemlos teilen und wiederholen lassen. Eine Suchseite mit ?q=seo&page=2 kann als Lesezeichen gespeichert, per E-Mail verschickt und von Suchmaschinen verarbeitet werden. Genau darin liegt der große Vorteil gegenüber Daten, die nur im temporären Speicher des Browsers liegen.

Wann sich die URL als Transportweg eignet

GET-Parameter passen zu Vorgängen, bei denen jemand Informationen lesen, filtern oder auswählen möchte. Typische Beispiele sind Suchbegriffe, Kategorien, Sprachversionen, Sortierungen, Seitenzahlen und Datumsbereiche.

• /blog?tag=javascript filtert Beiträge nach einem Thema.
• /produkte?min=50&max=200 begrenzt einen Preisbereich.
• /suche?q=cloud&page=3 zeigt eine bestimmte Ergebnisseite.
• /kalender?month=2026-08 wählt einen Zeitraum aus.

Ein GET-Aufruf sollte nach der HTTP-Semantik keine dauerhafte Änderung auslösen. Das Anzeigen einer gefilterten Liste ist passend, das Löschen eines Kontos über eine URL wie /delete?id=42 dagegen ein gefährliches Design. Auch wenn ein Framework technisch beide Varianten verarbeiten kann, trenne ich solche Aktionen klar und verwende dafür einen geeigneten Schreibzugriff mit zusätzlichem Schutz gegen ungewollte Anfragen.

Die Alternative ist meist POST. Dabei liegen die Nutzdaten im Request-Body und nicht sichtbar in der URL. Für Logins, Bestellungen, Uploads und Änderungen an Daten ist POST in der Regel die bessere Wahl, wobei auch dort Authentifizierung, Berechtigungsprüfung und CSRF-Schutz notwendig bleiben.

GET-Parameter mit JavaScript und Frameworks auslesen

Im Frontend greife ich nicht per String-Splitting auf die URL zu. Die Web API URLSearchParams übernimmt Dekodierung und Zugriff auf einzelne Werte deutlich zuverlässiger.

const params = new URLSearchParams(window.location.search);

const query = params.get("q") ?? "";
const page = Number.parseInt(params.get("page") ?? "1", 10);

console.log(query, page);

get() liefert null, wenn ein Parameter fehlt. Das ist wichtig, weil alle Werte zunächst Zeichenketten sind. Ein Wert wie page=2 wird nicht automatisch zur Zahl, deshalb sollte die Anwendung ihn ausdrücklich umwandeln und anschließend auf einen sinnvollen Bereich prüfen.

Mehrfach vorkommende Parameter lassen sich mit getAll() lesen. Das ist praktisch für Filter mit mehreren Auswahlwerten.

const params = new URLSearchParams("?tag=ai&tag=webentwicklung");
const tags = params.getAll("tag");

console.log(tags); // ["ai", "webentwicklung"]

In React, Vue oder Svelte bleibt das Prinzip gleich. Das Framework verändert höchstens, wann der Wert gelesen und wie eine Änderung im Interface verarbeitet wird. Bei einer clientseitigen Navigation sollte die Komponente auf URL-Änderungen reagieren, damit Browser-Zurück, Vorwärtsnavigation und direkte Links konsistent funktionieren.

Für neue URLs verwende ich den Konstruktor URL statt manueller Verkettung. Sonderzeichen, Leerzeichen und vorhandene Parameter werden dadurch korrekt behandelt.

const url = new URL("/suche", window.location.origin);

url.searchParams.set("q", "künstliche Intelligenz");
url.searchParams.set("page", "1");

history.pushState({}, "", url);

Auch serverseitig bieten Frameworks fertige Parser. In Express wird beispielsweise req.query verwendet, in PHP greift man häufig auf $_GET zu. In beiden Fällen gilt dieselbe Regel: Ein eingelesener Parameter ist noch keine vertrauenswürdige Eingabe.

app.get("/produkte", (req, res) => {
  const category = typeof req.query.category === "string"
    ? req.query.category
    : "";

  const allowed = ["laptop", "monitor", "zubehör"];
  const selected = allowed.includes(category) ? category : null;

  res.json({ category: selected });
});

Encoding, leere Werte und doppelte Namen richtig behandeln

URLs dürfen nicht jedes Zeichen unverändert enthalten. Leerzeichen, Umlaute, kaufmännische Und-Zeichen und Fragezeichen müssen korrekt codiert werden. Aus künstliche Intelligenz wird in einer URL beispielsweise eine percent-kodierte Darstellung, die der Browser beim Auslesen wieder in lesbaren Text umwandelt.

Manuelles Ersetzen von Zeichen ist fehleranfällig. Ich lasse diese Arbeit grundsätzlich URLSearchParams oder den jeweiligen Serverbibliotheken. So wird aus einem Suchbegriff mit & nicht versehentlich ein zusätzlicher Parameter.

const params = new URLSearchParams();
params.set("q", "R&D für Webteams");

console.log(params.toString());

Ein fehlender Parameter, ein leerer Wert und der Text null sind drei unterschiedliche Fälle. /suche, /suche?q= und /suche?q=null sollten nicht automatisch gleich behandelt werden. Definiere deshalb pro Parameter, ob er erforderlich ist, welchen Standardwert er besitzt und welche Form erlaubt ist.

Bei Listen gibt es mehrere gängige Schreibweisen, etwa tag=ai&tag=seo oder tags=ai,seo. Ich bevorzuge wiederholte Schlüssel, wenn die verwendete Bibliothek sie sauber unterstützt. Kommagetrennte Listen wirken zwar kompakt, müssen aber zusätzlich auf leere Einträge, Leerzeichen und unerlaubte Werte geprüft werden.

Doppelte Namen sind ein weiterer Stolperstein. Je nach Server, Proxy oder Framework kann bei role=user&role=admin der erste, der letzte oder eine Liste der Werte verwendet werden. Diese Uneinheitlichkeit kann Sicherheitsprobleme schaffen. Für sensible Entscheidungen sollte die Anwendung doppelte Parameter ablehnen oder eindeutig als Liste verarbeiten.

Sicherheit und Datenschutz dürfen nicht nachträglich kommen

Alles, was in der URL steht, kann in Browser-Historien, Server-Logs, Analysewerkzeugen, Screenshots und Referrer-Daten auftauchen. Deshalb gehören Passwörter, Zugangstokens, Kreditkartendaten und personenbezogene Geheimnisse nicht in Query-Parameter.

OWASP weist außerdem darauf hin, dass Parameter in GET-Anfragen besonders leicht verändert werden können. Ein Angreifer kann Werte direkt in der Adresszeile manipulieren, deshalb darf der Server niemals davon ausgehen, dass ein Parameter aus einer vertrauenswürdigen Quelle stammt.

Eingaben prüfen statt nur bereinigen

Validierung bedeutet, eine Eingabe gegen klare Regeln zu prüfen. Für eine Seitenzahl erwarte ich etwa eine ganze Zahl zwischen 1 und 1000, für eine Sortierung nur eine kleine erlaubte Liste wie price-asc oder name. Alles andere wird abgelehnt oder auf einen sicheren Standard zurückgesetzt.

Das schützt unter anderem vor unerwarteten Datenbankabfragen, Logikfehlern und HTTP Parameter Pollution. Für Datenbankzugriffe kommen zusätzlich vorbereitete Statements oder ein ORM mit sicherer Parameterbindung zum Einsatz. Das einfache Entfernen einzelner Zeichen ist kein verlässlicher Schutz gegen SQL-Injection.

Lesen Sie auch: Softwarebeispiele für Webentwicklung und passende Frameworks

Ausgaben ebenfalls absichern

Ein Suchwert kann nicht nur eine Datenbankabfrage beeinflussen, sondern später auch im HTML erscheinen. Wird der Inhalt ungefiltert in die Seite geschrieben, kann daraus Cross-Site-Scripting werden. Ich escape Benutzereingaben bei der Ausgabe und vermeide insbesondere innerHTML, wenn reiner Text genügt.

Auch Weiterleitungen brauchen eine Prüfung. Ein Parameter wie redirect=/konto darf nicht ohne Whitelist zu einer beliebigen externen Adresse führen. Sonst entsteht eine offene Weiterleitung, die für Phishing missbraucht werden kann.

Typische Fehler beim Einsatz in Projekten

Die meisten Probleme entstehen nicht beim Lesen der URL, sondern bei falschen Annahmen über ihre Werte. Diese Fehler sehe ich besonders häufig:

• Keine Typumwandlung: Zeichenketten werden direkt mit Zahlen verglichen oder an Datenbankabfragen weitergereicht.
• Fehlende Standardwerte: Die Anwendung bricht ab, wenn ein optionaler Parameter nicht vorhanden ist.
• Vertrauen in den Browser: Ein verstecktes Feld oder eine URL macht eine Berechtigung nicht gültig.
• Geheimnisse in Links: Session-Tokens oder Einmalcodes bleiben in Verlauf und Logs zurück.
• Manuelles URL-Bauen: Sonderzeichen zerstören die Syntax oder verändern die Bedeutung anderer Parameter.
• Uneinheitliche Benennung: Ein Teil des Systems erwartet sortBy, ein anderer sort.

Beim Testen prüfe ich nicht nur den Idealfall. Ich rufe die Seite ohne Parameter auf, verwende leere Werte, sehr lange Eingaben, ungültige Zahlen, Umlaute, doppelte Schlüssel und unerwartete Sonderzeichen. Anschließend kontrolliere ich, ob die Anwendung verständlich reagiert und ob im Server-Log sensible Daten landen.

Für öffentliche Schnittstellen lohnt sich zusätzlich eine dokumentierte Parameterliste. Sie sollte pro Feld den Datentyp, den Standardwert, erlaubte Werte und das Verhalten bei Fehlern nennen. Das spart später viel Zeit, besonders wenn mehrere Frontends oder externe Integrationen dieselbe API verwenden.

Eine belastbare Praxis für jede neue URL

Ich beginne bei jedem neuen Parameter mit einer einfachen Frage: Ist dieser Wert Teil des lesbaren Zustands einer Seite? Wenn ja, passt die URL meist gut. Wenn er eine Änderung auslöst, geheim bleiben muss oder sehr umfangreich ist, sollte er in einen geeigneteren Request-Mechanismus.

• Benenne Parameter eindeutig und konsistent.
• Definiere Typ, Pflichtstatus und Standardwert.
• Nutze URLSearchParams oder Framework-Parser.
• Validiere jeden Wert serverseitig gegen erlaubte Regeln.
• Verwende keine vertraulichen Informationen in der URL.
• Teste fehlende, leere, doppelte und manipulierte Eingaben.
• Dokumentiere die URL-Struktur für andere Entwickler.

So bleiben Links teilbar, Such- und Filterfunktionen verständlich und Schnittstellen leichter wartbar. Der wichtigste Gedanke ist dabei simpel: GET-Parameter beschreiben, was angezeigt werden soll, aber sie beweisen nicht, was ein Nutzer darf. Die eigentliche Sicherheit entsteht erst durch saubere Prüfung und durch eine klare Trennung zwischen Lesen und Verändern.