axios im Detail: Konfiguration, Antwortschema und Sicherheitsnotizen

Warum axios mit Promises im Browser und in Node.js läuft

axios ist ein Promise-basierter HTTP-Client, der dieselbe API im Browser und in Node.js anbietet. Genau diese Doppelrolle erklärt die weite Verbreitung mit über 109.000 Stars auf GitHub: Frontend-Code für Requests lässt sich ohne Abstraktionsschicht in serverseitige Tools und Tests übernehmen. Die README zählt die Kernfunktionen in einer Liste auf, die ein gutes Bild der Fähigkeiten liefert.

Dort stehen XMLHttpRequests im Browser und http-Anfragen in Node.js, Abfangen von Requests und Responses über Interceptors, Transformation von Anfrage- und Antwortdaten sowie das Abbrechen von Requests über eingebaute Abbruch-APIs. Außerdem beherrscht die Bibliothek die Serialisierung von Datenobjekten zu multipart/form-data und application/x-www-form-urlencoded, automatisches JSON-Parsing und clientseitigen Schutz gegen Cross-Site Request Forgery. Die Browserunterstützungstabelle nennt Chrome, Firefox, Safari, Opera und Edge, jeweils als aktuelle Versionen geführt. Die Pflege ist aktiv, am 24. August 2026 erschien Release v1.20.0.

Installation von npm install axios bis deno add axios

Die README deckt fünf Paketmanager ab: npm install axios, yarn add axios, pnpm add axios, bun add axios und deno add axios. Für direkte Browsernutzung stehen CDN-Links über jsDelivr und unpkg bereit, was Schnelltests ohne Build-Schritt möglich macht. Nach der Installation importiert man das Paket mit import axios, { isCancel, AxiosError } from 'axios' oder per CommonJS mit const axios = require('axios').

Dabei gibt es einen dokumentierten Unterschied: require liefert nur den Standardexport, benannte Zusätze wie isCancel oder AxiosError sind auf dem CommonJS-Pfad nicht verfügbar. Für ältere Umgebungen erwähnt das README zudem ein Bundle unter axios/dist/browser/axios.cjs. Wer auf eine Node.js-Version mit voller CommonJS-Unterstützung setzt, sollte diesen Pfad und die eigene Importweise vor dem Rollout im eigenen Build prüfen, da sich hier je nach Bundler-Setup Details unterscheiden können.

GET mit params, POST mit Body und Promise.all für parallele Requests

Die Beispiele im README zeigen die alltäglichen Muster. Ein GET läuft als await axios.get('/user?ID=12345') innerhalb von try/catch, eine Variante übergibt stattdessen ein params-Objekt zusammen mit einem timeout von 5000 ms. Für Schreiboperationen folgt ein POST-Beispiel, das einen JSON-Body sendet, und für parallele Requests ein Aufbau mit Promise.all und zwei Funktionen, die jeweils ein Promise von axios.get zurückgeben.

Zwei Warnungen stecken in diesem Abschnitt. Ohne gesetztes timeout kann eine stockende Anfrage unbegrenzt hängen, was gerade in Serverprozessen teuer werden kann, weil Verbindungen und Ressourcen blockiert bleiben. Außerdem weist das README darauf hin, dass async/await Teil von ECMAScript 2017 ist und in Internet Explorer nicht unterstützt wird. Für moderne Umgebungen ist das irrelevant, für Legacy-Ketten mit älteren Browsern bleibt es eine echte Beschränkung der Beispielform.

Instanzen über axios.create und das Ende von axios.all

Die API erlaubt zwei Aufrufformen: axios({ method, url, data }) mit einem vollständigen Konfigurationsobjekt oder axios(url[, config]) mit einer URL und optionaler Konfiguration. Für die gängigen HTTP-Verben existieren Aliase wie get, delete, head, options, post, put und patch, dazu request für den allgemeinen Fall. Eigene Instanzen entstehen mit axios.create([config]), etwa mit { baseURL, timeout, headers } als Startkonfiguration.

Solche Instanzen besitzen dieselben Methodenaliase und zusätzlich getUri, was sie zum Standardwerkzeug macht, wenn mehrere Backends oder APIs mit unterschiedlichen Basispfaden bedient werden. An einer Stelle räumt das README auf: Die Parallelitätshelfer axios.all und axios.spread gelten als veraltet, empfohlen wird stattdessen Promise.all. Bestehender Code mit axios.all funktioniert zwar weiterhin, neue Projekte sollten aber direkt auf Promise.all setzen, da die Helfer als Deprecated markiert sind.

maxContentLength, baseURL und der XSRF-Hinweis in der Konfiguration

Die Anfragekonfiguration ist der umfangreichste Teil der README. Nur url ist zwingend, die Standardmethode ist get. Zu den wichtigsten Optionen gehören baseURL, transformRequest, transformResponse, headers, params, paramsSerializer, data, timeout mit Standardwert 0, withCredentials, adapter, auth, responseType, maxContentLength, maxBodyLength, validateStatus, maxRedirects und sensitiveHeaders.

An dieser Stelle stehen auch die wichtigsten Sicherheitsnotizen. Standardmäßig sind maxContentLength und maxBodyLength auf -1 gesetzt, also unbegrenzt. Ein bösartiger Server könnte einen winzigen komprimierten Body senden, der beim Dekomprimieren auf Gigabytes anschwillt; die README empfiehlt deshalb ausdrücklich, ein Limit zu setzen. Ein zweiter Hinweis betrifft baseURL: Sie ist keine Sicherheitsgrenze, weil relative URLs Segmente wie .. enthalten können, die den Pfad nach oben verlassen. Der paramsSerializer lässt sich für strikte RFC-3986-Prozentkodierung konfigurieren. Wer diese drei Punkte in seiner eigenen Konfiguration nicht geprüft hat, übernimmt Standardwerte, die im Fehlerfall unangenehm auffallen.

Das Antwortschema mit data, status, headers und request

Jede Response folgt einem festen Schema mit sechs Feldern. data enthält die vom Server gelieferte Antwort, status den HTTP-Statuscode, statusText die Statusmeldung, headers die Response-Header mit kleingeschriebenen Namen, config die für die Anfrage verwendete Konfiguration und request die letzte ClientRequest-Instanz in Node.js beziehungsweise das XMLHttpRequest-Objekt im Browser.

Dieses Schema ist der Grund, warum Fehlerbehandlung bei axios so mechanisch abläuft: catch erhält ein AxiosError-Objekt, über das sich response.status und response.data auslesen lassen, ohne auf plattformabhängige Details zu stoßen. Das README beschreibt außerdem eine experimentelle HTTP/2-Unterstützung im Node.js-Adapter. Sie hängt von der Laufzeit und der Node.js-Version ab, und Umleitungen sowie das Adapterverhalten können von HTTP/1.1 abweichen. Für kritische Pfade bedeutet das: HTTP/2-Fähigkeiten vor dem produktiven Einsatz gegen den eigenen Endpoint testen, statt das Experiment als gegeben anzunehmen.

v1.20.0 im August 2026 und die Grenzen gegen native fetch

Die Release-Historie zeigt kontinuierliche Arbeit: v1.18.1 erschien am 21. Juni 2026, v1.19.0 am 26. Juli, v1.20.0 am 24. August 2026. Mit 11829 Forks und nur 79 offenen Issues auf GitHub dokumentiert das Projekt eine gesunde Community-Balance zwischen Nutzung und Betreuung. Die Lizenz ist MIT, die Dokumentation liegt unter axios-http.com.

Gegenüber nativem fetch gibt es einen ehrlichen Nachteil: axios ist ein zusätzlicher Abhängigkeitspaket im Bundle, während fetch in modernen Browsern und ab aktuellen Node.js-Versionen direkt verfügbar ist. Wofür sich axios dennoch lohnt, sind die Interceptors, das feste Antwortschema, automatische JSON-Serialisierung und der XSRF-Schutz, die in fetch-Projekten sonst manuell nachgebaut werden müssen. Wer keine dieser Funktionen braucht, fährt mit fetch schlanker. Wer sie braucht, bekommt mit axios einen Client, dessen Konfigurationsoptionen wie maxContentLength und validateStatus genau das steuern, was fetch offen lässt.

Redaktionelles Fazit

axios eignet sich für Projekte, die einen erprobten HTTP-Client mit Interceptors und Datentransformation im Browser wie in Node.js suchen. Wer ausschließlich native fetch nutzen will, braucht es weniger. Vor dem Einsatz lohnt ein Blick auf die eigene Anfragekonfiguration: maxContentLength setzen und baseURL-Kombinationen mit relativen URLs prüfen, wie es die README selbst empfiehlt.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes