Schnittstellen sicher anbieten
Eine Schnittstelle soll eine klar begrenzte Aufgabe erfüllen und nur die dafür benötigten Daten bereitstellen. Prüfen Sie vor der Implementierung, ob die Core-API oder eine eigene Route passt. Beide benötigen Authentifizierung und konkrete Berechtigungen.
Core-API und eigene Routen unterscheiden
Unter Verwaltung → System & Einstellungen → API gibt es Einstellungen, Integrationen und Bereiche. Bevor Sie die API aktivieren, beachten Sie den Hinweis der Oberfläche: der Webserver den HTTP-Authorization-Header an Concrete weiterreichen muss; ein Proxy kann ihn sonst entfernen. Aktivieren Sie die API erst auf einer Testkopie, wenn Authentifizierung, Scopes und die tatsächlich benötigten Endpunkte geklärt sind.
Abbildung 1: Der Bereich API zeigt die Einstellungen, bevor eine Schnittstelle aktiviert wird.
Eine eigene Route ist ein anderer Erweiterungsweg. Der Core-Router registriert HTTP-Verben wie GET und POST. Eine Route kann auch in einem Package liegen, doch ein URL-Pfad ohne Authentifizierung oder Rechteprüfung ist noch keine sichere API. Die offizielle Route-Dokumentation (EN) (externer Link) beschreibt Registrierung und Middleware; gleichen Sie die Beispiele mit dem aktuellen Core und Ihrem Package-Aufbau ab.
Einen Anwendungsfall begrenzen
Begrenzen Sie eine interne Liste von Schulungsanfragen auf den nötigen Zugriff. Klären Sie vor dem Code: Soll nur eine Gruppe sie lesen? Welche Felder sind nötig? Sind Namen und E-Mail-Adressen enthalten? Darf die Abfrage alle Einträge oder nur eine Seite von Ergebnissen liefern? Gibt es einen Lösch- oder Exportprozess? In vielen Fällen genügt die bestehende Express-Verwaltung; eine neue API erhöht die Zahl möglicher Zugriffe.
Beim Lesen und Schreiben prüfen Sie die Identität der aufrufenden Person, deren konkrete Berechtigung für diesen Datensatz, das Format der Eingaben und eine maximale Ergebnisgröße. Ein CSRF-Token schützt browsergebundene Aktionen vor fremden Formularen; es ersetzt weder eine Anmeldung noch Objektberechtigungen. Geben Sie bei Fehlern eine klare HTTP-Antwort aus, aber keine Zugangsdaten, SQL-Fehler oder internen Pfade.
Test und Betrieb
Testen Sie ohne Anmeldung, mit erlaubter und nicht erlaubter Rolle, mit ungültigen IDs, fehlenden Parametern, überlangen Werten und mehreren gleichzeitigen Anfragen. Prüfen Sie Weitergabe des Authorization-Headers auf dem tatsächlichen Webserver. Protokollieren Sie genug für die Fehlersuche, aber keine Geheimnisse oder vollständigen sensiblen Nutzdaten. Zugangstoken gehören in eine geschützte Konfiguration und müssen widerrufbar sein.
Für das zugrunde liegende Datenmodell lesen Sie Daten und Express; für Formularprüfungen Formulare gestalten.
Weiterlesen
- Daten und Express in Erweiterungen verwenden
- Sonderseiten und eigene Routen entwickeln
- Erweiterungen gegen unbefugte Eingaben absichern
Quelle: Concrete CMS Dokumentation (EN) · Stand: ConcreteCMS 9.5.7