# REST-APIs in PHP absichern

> REST-APIs in PHP absichern: Authentifizierung, Prüfung je Objekt, JWT, Größen- und Typgrenzen, Fehlermeldungen und Ratenbegrenzung mit Beispielcode.

Quelle: https://phpsos.de/blog/rest-api-php-absichern/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kurz gesagt:** Für die API-Sicherheit in PHP zählen vor allem fünf Punkte: nur HTTPS, Authentifizierung an jedem nicht öffentlichen Endpunkt, Berechtigungsprüfung für jedes einzelne Objekt, strikte Grenzen für Methode, Inhaltstyp und Größe der Anfrage sowie knappe Fehlermeldungen ohne interne Details. Dazu kommen Ratenbegrenzung und ein Protokoll sicherheitsrelevanter Ereignisse. Gegen Lücken im PHP-Interpreter selbst wie PHP2Shell hilft das nicht; dafür braucht es das PHP-Update.

## Die Schnittstelle hinter der Website

Viele Unternehmen haben in der Woche nach dem 21.10.2026 ihre Websites geprüft. Die Schnittstellen dahinter standen seltener auf der Liste. Dabei laufen gerade dort sensible Vorgänge: Die App des Kundenportals holt Rechnungen ab, das Warenwirtschaftssystem schreibt Bestände in den Shop, ein Partner meldet Aufträge per Webhook. Oft wurden diese APIs schnell gebaut, für einen einzigen Zweck, und danach nie wieder angesehen.

Eine API hat keine Oberfläche, die Fehler sichtbar macht. Ein fehlender Berechtigungscheck fällt im Alltag niemandem auf, solange alle Clients nur das abfragen, was sie sollen. Ein Angreifer probiert dagegen genau das, was nicht vorgesehen ist.

Der erste Schritt ist deshalb eine Bestandsaufnahme. Welche Endpunkte gibt es überhaupt? Häufig finden sich alte Versionen wie `/api/v1/`, die nach dem Umstieg auf `/v2/` nie abgeschaltet wurden, Testendpunkte aus der Entwicklung oder eine öffentlich abrufbare Schnittstellenbeschreibung, die interne Funktionen auflistet. Jeder Endpunkt, der nicht mehr gebraucht wird, sollte abgeschaltet werden. Jeder, der bleibt, braucht einen Verantwortlichen.

## API-Sicherheit in PHP: die Grundregeln

Das OWASP REST Security Cheat Sheet fasst bewährte Regeln zusammen. Für PHP-Projekte lassen sie sich in eine kurze Liste übersetzen:

1. **Nur HTTPS.** Tokens und Zugangsdaten dürfen nie unverschlüsselt übertragen werden.
2. **Jeder Endpunkt prüft selbst.** Die Authentifizierung kann zentral erfolgen, die Entscheidung über den Zugriff fällt am Endpunkt.
3. **Berechtigung je Objekt.** Nicht nur „ist angemeldet“, sondern „darf genau diesen Datensatz“.
4. **Erlaubte Methoden festlegen.** Was nicht ausdrücklich erlaubt ist, wird mit 405 abgelehnt.
5. **Inhaltstyp und Größe prüfen.** Falscher Typ ergibt 415, zu große Anfragen 413.
6. **Eingaben validieren.** Typ, Länge, Format und Wertebereich, serverseitig.
7. **Keine Geheimnisse in URLs.** Tokens und Schlüssel gehören in Header, nicht in den Query-String.
8. **Knappe Fehler.** Keine Stacktraces, Pfade oder SQL-Meldungen an den Client.
9. **Ratenbegrenzung.** Zu viele Anfragen werden mit 429 beantwortet.
10. **Verwaltungsendpunkte abschirmen.** Nicht öffentlich erreichbar oder nur mit starker Anmeldung.

## Objektberechtigung: der häufigste Fehler

Ein Beispiel macht das Problem greifbar. Ein Endpunkt liefert Rechnungen unter `/api/rechnungen/{id}`. Geprüft wird, ob ein gültiges Token vorliegt. Nicht geprüft wird, ob die Rechnung zum Kunden des Tokens gehört. Wer seine eigene Rechnungsnummer um eins erhöht, sieht die des Nachbarn.

Die Lösung ist einfach und muss trotzdem an jeder Stelle umgesetzt werden: Die Abfrage selbst schränkt auf den berechtigten Bereich ein.

```php
<?php
// Nur Methode GET erlauben
if ($_SERVER['REQUEST_METHOD'] !== 'GET') {
    http_response_code(405);
    header('Allow: GET');
    exit;
}

$kundeId = $auth->kundeId();          // aus dem geprüften Token
$id = filter_var($routeId, FILTER_VALIDATE_INT);
if ($id === false) {
    http_response_code(400);
    exit;
}

// Berechtigung steckt in der Abfrage: nur eigene Rechnungen
$stmt = $pdo->prepare('SELECT nummer, betrag, datum FROM rechnungen WHERE id = ? AND kunde_id = ?');
$stmt->execute([$id, $kundeId]);
$rechnung = $stmt->fetch(PDO::FETCH_ASSOC);

if (!$rechnung) {
    http_response_code(404);           // nicht verraten, ob es die ID gibt
    exit;
}

header('Content-Type: application/json');
echo json_encode($rechnung, JSON_THROW_ON_ERROR);
```

Die Abfrage mit Platzhaltern schützt zugleich vor SQL-Injection, siehe [SQL-Injection in PHP verhindern](https://phpsos.de/ratgeber/sql-injection-php/). Wie PHP Anfragedaten wie Methode, Header und Body bereitstellt, erklärt [Superglobals: $_GET, $_POST, $_FILES und Co.](https://phpsos.de/php/superglobals/).

## Tokens richtig prüfen

Viele APIs arbeiten mit JSON Web Tokens. Das OWASP Cheat Sheet nennt dafür klare Regeln: Tokens müssen signiert sein, unsignierte Tokens werden abgelehnt, und der Algorithmus für die Prüfung wird auf dem Server festgelegt, nicht aus dem Token übernommen. Aussteller, Zielgruppe und Ablaufzeit gehören ebenfalls zur Prüfung. Nutzen Sie dafür eine gepflegte Bibliothek statt eigener Implementierungen.

Eigene Tokens, etwa für Webhooks oder Einmal-Links, müssen aus einem kryptografisch sicheren Zufallsgenerator stammen und in konstanter Zeit verglichen werden. Wie das in PHP geht, zeigt [Sichere Zufallszahlen und Tokens in PHP](https://phpsos.de/blog/sichere-tokens-php/).

> **Tipp:**
> Geben Sie jedem Client und jedem Partner einen eigenen Schlüssel mit genau den Rechten, die er braucht. Dann lässt sich ein abgeflossener Schlüssel einzeln sperren, ohne alle anderen Anbindungen zu unterbrechen.

## Grenzen setzen: Größe, Typ und Tempo

Eine API sollte nur annehmen, was sie erwartet. Das beginnt beim Inhaltstyp: Ein Endpunkt, der JSON verarbeitet, lehnt alles andere ab. Die maximale Größe einer Anfrage begrenzen Sie auf mehreren Ebenen, im Webserver und in PHP über `post_max_size`. Diese Grenze gehört auch zu den Übergangsmaßnahmen, die php.net zu PHP2Shell genannt hat. Wie man sie sinnvoll wählt, beschreibt [post_max_size und upload_max_filesize sinnvoll begrenzen](https://phpsos.de/blog/post-max-size-upload-limits/).

Ratenbegrenzung schützt vor dem Durchprobieren von Kennungen und vor Überlastung. Sie lässt sich im Webserver, in einem vorgeschalteten Proxy oder in der Anwendung umsetzen. Wichtig ist, dass Grenzen je Schlüssel oder Nutzer gelten und nicht nur je IP-Adresse.

Für APIs, die direkt aus dem Browser aufgerufen werden, kommt CORS hinzu, also die Regeln, welche fremden Websites Anfragen stellen dürfen. Setzen Sie diese Header nur, wenn solche Aufrufe wirklich vorgesehen sind, und nennen Sie die erlaubten Herkünfte einzeln, statt jede Herkunft zuzulassen. Ein Platzhalter, der alle Websites erlaubt, ist bei Endpunkten mit Anmeldung fast immer ein Fehler.

Zuletzt das Protokoll: Fehlgeschlagene Anmeldungen, abgelehnte Tokens und verweigerte Zugriffe gehören ins Log, Tokens selbst nicht. Ohne diese Einträge bleibt ein Angriff auf die API unsichtbar.

## Wie hilft PHP SOS konkret?

- Wir erfassen alle Schnittstellen Ihrer PHP-Systeme, auch vergessene und interne, und prüfen, welche öffentlich erreichbar sind.
- Wir lesen die Berechtigungslogik und testen gezielt, ob fremde Datensätze abrufbar sind.
- Wir setzen Grenzen für Größe, Typ und Tempo in Webserver und PHP und stimmen sie mit Ihren Clients ab.
- Für eine umfassende Prüfung von außen kombinieren wir das mit [Sicherheitsaudit und Penetrationstest](https://phpsos.de/leistungen/sicherheitsaudit-penetrationstest/).

**Fazit:** Eine API ist so sicher wie ihr nachlässigster Endpunkt. Wer Berechtigungen je Objekt prüft, klare Grenzen setzt und Fehler knapp hält, schließt die häufigsten Lücken, lange bevor jemand gezielt danach sucht.


## Häufige Fragen

**Reicht ein API-Schlüssel als Schutz?**  
Für sensible Daten nicht. Ein API-Schlüssel identifiziert meist eine Anwendung, nicht einen Nutzer, und wird leicht weitergegeben. Das OWASP REST Security Cheat Sheet rät, API-Schlüssel nicht als alleinigen Schutz für sensible Ressourcen zu verwenden.

**Was ist eine Objektberechtigung und warum fehlt sie so oft?**  
Gemeint ist die Prüfung, ob der angemeldete Nutzer genau diesen Datensatz sehen oder ändern darf. Sie fehlt oft, weil Entwickler nur prüfen, ob überhaupt jemand angemeldet ist. Dann reicht es, eine Kennung in der URL zu ändern, um fremde Daten abzurufen.

**Schützt eine gut abgesicherte API vor PHP2Shell?**  
Nein. PHP2Shell steckt im PHP-Interpreter und wirkt bei betroffenen Betriebsarten, bevor Ihr Code überhaupt läuft. Dagegen hilft nur ein PHP-Update mit Neustart. Größengrenzen für Anfragen sind trotzdem sinnvoll und gehören auch zu den Übergangsmaßnahmen von php.net.

**Welche Statuscodes sollte eine API bei Sicherheitsfehlern liefern?**  
Üblich sind 401 ohne gültige Anmeldung, 403 bei fehlender Berechtigung, 405 bei nicht erlaubter Methode, 413 bei zu großer Anfrage, 415 bei falschem Inhaltstyp und 429 bei zu vielen Anfragen. Die Antwort selbst bleibt dabei knapp und ohne interne Details.

## Quellen

- [OWASP: REST Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [PHP-Handbuch](https://www.php.net/manual/de/)
- [php.net: Sicherheitsmeldungen](https://www.php.net/)