Eine alte Produktseite verwendet ?produkt=42, während die neue Struktur die ID im Pfad erwartet. Zugleich sollen Trackingparameter erhalten bleiben. Eine hastig formulierte Regel verliert jedoch den Produktfilter und übernimmt einen frei angegebenen Zielhost – damit wird aus einer Komfortfunktion ein Sicherheitsrisiko.
Bevor Sie eine URL mit Query-Parametern weiterleiten, brauchen Sie klare Regeln für jeden Parameternamen: Ist er Teil der Ressource, nur vorübergehender Zustand oder vertrauliche Eingabe?
Inhaltsverzeichnis
Was Query-Weiterleitungen steuern
Eine Query-Regel legt fest, welche Parameter für das Matching relevant sind und welche Werte das Ziel erhält. Reihenfolge, mehrfache Schlüssel, leere Werte und URL-Codierung können die Bedeutung verändern. Ein Parameter darf daher nicht pauschal verworfen oder ungeprüft in eine Ziel-URL kopiert werden.
Praxisbeispiel
/produkt-alt?produkt=42&utm_source=mailsoll zu /produkt/42/?utm_source=mailführen. Die Produkt-ID wird nur akzeptiert, wenn sie numerisch ist; das Ziel bleibt auf der eigenen Domain. Ein unbekannter next-Parameter wird nicht als Host oder Zielpfad verwendet. Vorschau-Nonces und signierte Downloadwerte fallen gar nicht in den Geltungsbereich.
Tests decken eine zweite gültige ID, eine fehlende ID, doppelte Schlüssel, veränderte Reihenfolge und codierte Sonderzeichen ab. Warenkorb, Suche, REST-API und eine normale URL ohne Routingparameter bleiben unverändert.
Welche Parameter erhalten bleiben
Geschäftlich notwendige Filter, Produkt-IDs, Sprache oder Pagination können Teil der Zielressource sein. Trackingwerte lassen sich je nach Datenschutz- und Analyseregel erhalten oder bewusst entfernen. Nonces, Tokens, Signaturen und private Zustände gehören dagegen nicht in eine öffentliche Zieladresse.
Eine Positivliste zulässiger Namen und Werteformate ist sicherer als die Übernahme beliebiger Eingaben. Bauen Sie insbesondere nie einen externen Zielhost aus einem ungeprüften Parameter; andernfalls entsteht eine offene Weiterleitung, die für Phishing missbraucht werden kann.
Einfaches Vorgehen
- Notieren Sie für jede reale Quell-URL Pfad und relevante Parameter.
- Definieren Sie erlaubte Namen, Werteformate und das feste Ziel.
- Entscheiden Sie ausdrücklich, welche Trackingwerte erhalten bleiben.
- Schließen Sie Admin, Login, REST, Vorschau, Checkout und signierte Downloads aus.
- Testen Sie gültige, fehlende, zusätzliche, doppelte und codierte Werte.
Technische und sicherheitsbezogene Prüfung
Vergleichen Sie die rohe und die decodierte Query. Prüfen Sie Pluszeichen, Prozentcodierung, Arraynotation und wiederholte Schlüssel. WordPress, Webserver und CDN können Werte unterschiedlich normalisieren. Die Regel muss auf allen tatsächlich beteiligten Ebenen dieselbe Bedeutung haben.
Verfolgen Sie den ersten Statuscode und Location-Header ohne automatisches Folgen. Ein Query-Redirect sollte in der Regel nur für GET-Anfragen vorgesehen sein; bei POST, Webhooks oder Formularen kann ein Redirect Methode und Body beeinflussen. Achten Sie außerdem darauf, dass private Varianten nicht in einem gemeinsam genutzten Cache landen.
Risiken, Backup und Rollback
Lockere Muster verlieren Filter, verändern Codierung oder erfassen sicherheitsrelevante Routen. Ungeprüfte Ziele ermöglichen offene Redirects. Exportieren Sie bestehende Regeln und protokollieren Sie die zugelassenen Parameter, bevor Sie die Änderung aktivieren.
Bei einem falschen Ziel oder verlorenen Wert deaktivieren Sie die neue Regel. Stellen Sie keine weiteren Transformationen darüber. Vergleichen Sie anschließend die ursprüngliche Anfrage mit dem erwarteten Ziel und korrigieren Sie die Positivliste.
So unterstützt AIOWS:
AIOWS Weiterleitungs-Manager
AIOWS Weiterleitungs-Manager stellt unterstützte WordPress-Weiterleitungen zentral bereit. Für eine klar definierte alte URL kann dort eine nachvollziehbare Quelle-Ziel-Zuordnung verwaltet werden. Ob und wie Query-Parameter in einer konkreten Regel behandelt werden, muss vorab anhand des tatsächlichen Anwendungsfalls festgelegt werden.
Beginnen Sie mit einer kleinen Positivliste und einem festen internen Ziel. Testen Sie die gespeicherte Regel mit gültigen und ungültigen Werten, veränderter Reihenfolge, fehlenden Parametern und einer normalen Kontroll-URL. Prüfen Sie Statuscode, Location, Endinhalt und Canonical in einer Sitzung ohne Administrator-Cookie.
Der Manager kann keine fachliche Bedeutung unbekannter Parameter erkennen und darf nicht als Ersatz für Validierung oder Zugriffskontrolle dienen. Externe Hosts, Tokens und signierte Werte werden nicht ungeprüft übernommen. Verursacht die Regel einen offenen Redirect, einen verlorenen Filter oder unerwartete Treffer, wird sie deaktiviert und enger neu entworfen.
AIOWS Weiterleitungs-Manager ansehenAIOWS-Tarife vergleichen
Passende Artikel
- Regex-Weiterleitungen in WordPress erstellen
- Trailing-Slash-Weiterleitungen in WordPress richtig lösen
- Groß- und Kleinschreibung in WordPress-URLs richtig weiterleiten
Fazit
Behandeln Sie Query-Parameter wie einen klaren Datenvertrag. Übernehmen Sie nur bekannte Werte in ein festes erlaubtes Ziel und testen Sie fehlende, zusätzliche sowie codierte Varianten ausdrücklich.
