Fiddler für Tester 2026: Web-Debugging-Proxy für HTTPS und APIs

Fiddler war eines der ersten Tools, das ich als Tester ernsthaft eingesetzt habe: damals noch Fiddler Classic unter Windows, mit dem ich OAuth-Flows entwirren und seltsame 502er von Reverse-Proxies reproduzieren wollte. Heute, einige Jahre später, hat sich vieles verändert: HTTP/2 und gRPC sind Standard, Mobile- und macOS-Debugging gehören zum Pflichtprogramm, Fiddler Everywhere hat den Classic-Stand fast überall überholt. Was geblieben ist: Wenn Tests grün leuchten und die App trotzdem bockt, sehe ich mir zuerst an, was wirklich über die Leitung geht.

Ich nutze Fiddler in Projekten immer wieder an drei Stellen. Erstens bei Frontend-Bugs, die sich lokal nicht reproduzieren lassen. Dann hilft Mocking via AutoResponder, um eine Backend-Antwort kontrolliert nachzustellen. Zweitens bei Performance-Triage vor einem Lasttest: ein Blick auf den Timing-Tab spart oft Stunden in k6 oder JMeter. Drittens bei Ad-hoc-Security-Checks im Composer, wenn ich Auth-Header bewusst manipulieren möchte.

In diesem Beitrag ordne ich die heutigen Varianten Fiddler Classic und Fiddler Everywhere ein, zeige den HTTPS-Decryption-Setup-Workflow, die sechs Capturing-Modi sowie API-Mocking, Performance-Tab und die Abgrenzung zu Alternativen wie Charles, Burp Suite und mitmproxy.

Was ist Fiddler?

Fiddler ist ein lokaler HTTP- und HTTPS-Proxy. Er klemmt sich als Man-in-the-Middle zwischen Anwendung und Internet, protokolliert jeden Request und jede Response, erlaubt das Inspizieren von Headern und Bodies und kann Antworten manipulieren, ersetzen oder verzögern. Damit gehört Fiddler in die Kategorie der Web-Debugging-Proxies, neben Tools wie Charles, Burp Suite oder mitmproxy.

Entwickelt wurde Fiddler ursprünglich 2003 von Eric Lawrence bei Microsoft. Heute gehört das Produkt zu Progress Telerik. Laut Hersteller nutzen es weltweit mehr als vier Millionen Entwicklerinnen und Entwickler. Auf G2.com erreicht Fiddler 4,4 von 5 Sternen.

Typische Einsatzgebiete sind die Fehlersuche bei Web- und Mobile-Anwendungen, das Mocking von Backend-Antworten für Frontend-Tests, die Performance-Analyse vor einem Lasttest mit k6, JMeter oder Gatling sowie das Security-Testing in Pen-Tests, wenn du Anfragen gezielt manipulieren willst.

Fiddler Classic vs. Fiddler Everywhere 2026

Telerik führt zwei Varianten parallel: Fiddler Classic (das ursprüngliche Windows-Tool) und Fiddler Everywhere (die moderne Cross-Platform-Lösung). Beide Produkte sind nicht austauschbar, beide haben ihre Berechtigung. Die folgende Tabelle stellt die wichtigsten Unterschiede gegenüber:

Für neue Projekte empfehle ich Fiddler Everywhere. Wer noch produktiv mit Fiddler Classic arbeitet (etwa mit historisch gewachsenen FiddlerScript-Regeln), kann ihn weiter nutzen, sollte aber wissen, dass moderne Protokolle wie HTTP/2 und gRPC nicht abgedeckt sind. Für Mobile-Capturing auf iOS und Android ist Everywhere deutlich komfortabler.

Fiddler installieren und HTTPS entschlüsseln

Der Reiz von Fiddler liegt in der HTTPS-Inspektion. Ohne Entschlüsselung siehst du nur verschlüsselte Bytes, die dir wenig nützen. Der Setup-Workflow für Fiddler Everywhere unterscheidet sich je nach Plattform leicht, folgt aber demselben Muster:

1. Fiddler Everywhere von der Telerik-Website herunterladen und installieren.
2. Telerik-Account anlegen (Free-Tier reicht für Standard-Workflows).
3. Im Menü „Settings → HTTPS" das Capturing für HTTPS aktivieren.
4. Fiddler-Root-Zertifikat in den OS-Zertifikatsspeicher (Windows-Cert-Store, macOS-Keychain oder Linux-CA-Bundle) installieren. Fiddler bietet dafür einen geführten Dialog.
5. Browser oder Anwendung neu starten, damit das Zertifikat geladen wird.
6. Capturing starten und gezielt einen Request auslösen. Im Inspector lassen sich Header, Cookies, Body und Timing einsehen.

Wichtig zur Sicherheit: Das Fiddler-Root-Zertifikat verleiht Fiddler die technische Möglichkeit, jeden TLS-Traffic des Hosts mitzulesen. Das ist gewünscht, aber heißt auch: HTTPS-Decryption nur auf Entwicklungs- und Testmaschinen aktivieren, niemals auf produktiven Endgeräten. Nach dem Debugging das Zertifikat wieder entfernen.

Die sechs Capturing-Modi im Überblick

Fiddler Everywhere unterstützt sechs Capturing-Modi, die unterschiedliche Quellen abdecken. Die Auswahl hängt davon ab, was du debuggen willst:

Im Alltag dominiert System Capturing. Für Mobile-Tests empfehle ich Network Capturing in Kombination mit dem QR-Code-Setup: Smartphone und Fiddler-Host müssen im selben Netz sein, das Smartphone scannt den QR-Code, Fiddler installiert das Profil automatisch.

API-Mocking und AutoResponder

Eine der mächtigsten Funktionen ist der AutoResponder. Damit lassen sich Antworten von beliebigen URLs gegen vordefinierte Responses austauschen, ohne den Server zu ändern. Das ist ideal, um Fehlerzustände nachzustellen, etwa eine 503-Antwort eines Drittsystems, eine verzögerte Response oder einen leeren Datensatz.

Der Workflow ist immer ähnlich: URL-Pattern oder Regex definieren, gewünschte Response-Datei oder Status-Code hinterlegen, optional eine Latenz simulieren. Im Test-Frontend verhält sich das System, als hätte das echte Backend geantwortet. Damit ergänzt Fiddler API-Mocking-Werkzeuge wie Postman Mock-Server oder den Bruno-Test-Runner, ohne diese zu ersetzen. Postman und Bruno arbeiten auf API-Ebene, Fiddler dazwischen auf der Netzwerkschicht.

rule:
  match: "https://api.example.com/orders/*"
  response:
    status: 503
    headers:
      Retry-After: "120"
    body: |
      { "error": "service_unavailable", "id": "test-mock-1" }
    latency_ms: 800

Performance-Analyse mit dem Timing-Tab

Vor einem ausgewachsenen Lasttest lohnt sich oft eine Einzelrequest-Analyse. Der Timing-Tab in Fiddler zeigt für jeden Request die einzelnen Phasen: DNS-Auflösung, TCP-Connect, TLS-Handshake, Wartezeit auf den Server (TTFB), Empfangsdauer. Daraus lässt sich oft schon eine Hypothese ableiten: Liegt das Problem im Netzwerk, beim Server oder beim Rendering?

Drei typische Befunde, die ich in Projekten gesehen habe:

• Hohe TLS-Handshake-Zeit: Hinweis auf falsch konfigurierte Zertifikatskette, fehlende Session-Resumption oder regional weit entferntes Backend.
• Hohe TTFB: Server-Probleme, Datenbank-Locks, Cold-Start-Effekte bei Serverless-Funktionen.
• Hohe Receive-Zeit: Große Payloads ohne Kompression, langsame Verbindung, Throttling.

Fiddler ersetzt kein dediziertes APM-Tool, hilft aber bei der schnellen Voranalyse. Für strukturierte Performance-Strategien sieh dir unseren Beitrag zu Performance Testing in DevOps an.

Fiddler im Security- und Pen-Testing

Mit dem Composer-Feature lassen sich Requests bearbeiten und erneut senden. Damit wird Fiddler zum Werkzeug für gezielte Sicherheitstests: Header manipulieren, Body-Parameter ändern, Tokens auslassen, Cookies fälschen. Klassische Angriffsvektoren wie IDOR (Insecure Direct Object Reference), fehlende Autorisierungs-Checks oder schlecht validierte Eingaben lassen sich so reproduzieren.

Für strukturierte Penetrations-Tests ist Burp Suite umfassender, Fiddler ist jedoch eine gute Wahl, wenn du einen schnellen Ad-hoc-Test durchführen oder einem Entwicklungsteam eine Beobachtung demonstrieren willst. Für tieferes Wissen zu KI-gestütztem Security-Testing sieh dir den Beitrag zu Agentic AI Testing an.

Hinweis: Setz Fiddler ausschließlich gegen Systeme ein, deren Testen du autorisiert hast. Ohne Auftrag ist HTTPS-Interception gegen fremde Services rechtlich problematisch.

Fiddler vs. Charles, Burp und mitmproxy

Web-Debugging-Proxies gibt es viele. Die Auswahl hängt von Plattform, Use Case und Lizenzmodell ab:

Für reine Frontend-Debug-Sessions reicht Charles. Wer Penetrationstests durchführt, greift zu Burp. Für CLI-lastige Skript-Workflows ist mitmproxy unschlagbar. Fiddler positioniert sich dazwischen: GUI-Komfort plus Mocking-Funktionen plus Team-Features. In einer typischen QA-Toolchain neben API-Testing-Tools wie Postman und Bruno ist Fiddler die Network-Layer-Ergänzung.

Fazit

Fiddler bleibt 2026 eines der nützlichsten Werkzeuge in der Tester-Toolchain. Die moderne Cross-Platform-Variante Fiddler Everywhere ersetzt schrittweise Fiddler Classic, deckt HTTP/2, gRPC, WebSocket und Server-Sent Events ab und bietet vereinfachtes Mobile-Capturing. Wer einen Frontend-Bug nicht reproduzieren kann, eine API ohne Backend-Änderung mocken oder eine Performance-Vermutung schnell prüfen will, kommt mit Fiddler in Minuten zum Ziel.

Drei Empfehlungen für den Einstieg: Erstens, Fiddler Everywhere installieren und das Root-Zertifikat auf einer Test-Maschine einrichten, nicht auf deinem Produktivgerät. Zweitens, einen ersten Use Case wählen (Mocking via AutoResponder oder Mobile-Capturing). Drittens, Fiddler bewusst neben deine API-Testing-Tools stellen, nicht als Ersatz. Wenn du eine vollständige Toolchain-Strategie planst, sprich uns gerne an.

FAQ: Häufige Fragen zu Fiddler

Was ist Fiddler genau?

Fiddler ist ein lokaler HTTP- und HTTPS-Debugging-Proxy. Er protokolliert sämtlichen Netzwerk-Traffic der lokalen Anwendungen, erlaubt Inspektion und Modifikation und unterstützt Mocking via AutoResponder. Hersteller ist Progress Telerik. Weltweit setzen mehr als vier Millionen Entwickler das Tool ein.

Was ist der Unterschied zwischen Fiddler Classic und Fiddler Everywhere?

Fiddler Classic läuft nur unter Windows und befindet sich nicht mehr in aktiver Entwicklung. Fiddler Everywhere ist die moderne Cross-Platform-Lösung mit Unterstützung für HTTP/2, gRPC, WebSocket und Server-Sent Events. Für neue Projekte empfehle ich Everywhere, siehe Direktvergleich oben.

Wie aktiviere ich HTTPS-Decryption in Fiddler?

In den Settings unter „HTTPS" Capturing aktivieren und das Fiddler-Root-Zertifikat in den OS-Zertifikatsspeicher installieren. Browser und Anwendungen müssen neu gestartet werden. Aus Sicherheitsgründen solltest du das Zertifikat nur auf Test-Maschinen einrichten, nie auf produktiven Endgeräten.

Kann Fiddler Mobile-Traffic abfangen?

Ja. Im Network-Capturing-Modus stellt Fiddler Everywhere einen Proxy für externe Geräte bereit. Über einen QR-Code-Setup-Flow lassen sich iOS- und Android-Geräte mit wenigen Klicks konfigurieren. Das Smartphone muss sich im selben Netz wie der Fiddler-Host befinden.

Wann nutze ich Fiddler-Mocking statt Postman-Mocking?

Postman- und Bruno-Mocks laufen auf API-Ebene und ersetzen einen Server. Fiddler-Mocking via AutoResponder läuft lokal auf Netzwerkebene und greift in echten Traffic ein. Für Frontend-Tests ohne Backend-Änderung ist Fiddler oft schneller. Für Team-geteilte Mock-Server ist Postman oder Bruno die bessere Wahl.

Ersetzt Fiddler Burp Suite im Pen-Testing?

Nein. Burp Suite bietet aktive Scanning-Module, eine umfangreiche Extension-Sammlung und ist speziell auf Web-Application-Security ausgelegt. Fiddler eignet sich für gezielte Ad-hoc-Tests und Demonstrationen, aber nicht für strukturierte Penetrationstests einer kompletten Anwendung.

Ersetzt Fiddler ein APM-Tool?

Nein. Fiddler liefert einen schnellen Blick auf einzelne Requests, ein APM-Tool wie Datadog, New Relic oder Dynatrace überwacht das Gesamtsystem über lange Zeiträume mit Aggregationen, Alerts und Distributed-Tracing. Beide ergänzen sich, siehe Beitrag zu APM.