Sicherheit: Tabellen & Spalten sperren

->columns() ist keine Sicherheitsgrenze

Der Aufruf von ->columns('name', 'email') auf einer Seite ändert nur, was das eigene Grid dieser Seite anzeigt. An core/ajax_crud.php, dem REST-Endpunkt, mit dem das JavaScript jedes Widgets tatsächlich spricht, ändert er nichts - die API löst die Konfiguration einer Seite auf, indem sie deren Route erneut ausführt (xcrud_load_hooks_from_page()), aber welche Spalten eine echte Datenbanktabelle offenlegt, bestimmt das eigene Schema der Tabelle, nicht das, was eine Seite anzuzeigen entschieden hat. Ein Besucher, der die API direkt aufruft (DevTools öffnen, die Anfrage mit einer anderen route/Query wiederholen), wird durch keine ->columns()-Einschränkung einer Seite gebremst.

Mit anderen Worten: ->columns() ist eine Anzeige-Bequemlichkeit. Es ist niemals das, was zwischen einer sensiblen Spalte und dem Netzwerk steht.

$blacklistedTables - die eigentliche Tabellengrenze

Standardmäßig ist jede echte Tabelle in der verbundenen Datenbank über Xcrud erreichbar (live introspiziert, nichts muss vorher registriert werden) - $blacklistedTables in src/Config.php ist das, was eine Tabelle vollständig unerreichbar macht, egal was das eigene PHP einer Seite versucht:

public static array $blacklistedTables = [
    'sys_settings', 'sys_settings_other', 'sys_notifications', 'logs',
];

Eine gesperrte Tabelle kann niemals über ->table(), als ->relation()-Ziel oder als ->gallery()-Kindtabelle erreicht werden - der Aufruf von ->table('logs') wirft sofort eine Exception, statt stillschweigend ein leeres Grid zu rendern.

$blacklistedColumns - Sperrung auf Spaltenebene

Manche Tabellen dürfen generell offengelegt werden, haben aber bestimmte Spalten, die niemals über die API hin- und zurücklaufen sollten - ein Passwort-Hash, ein interner Token, eine veraltete Blob-Spalte. $blacklistedColumns sperrt diese Spalten innerhalb einer ansonsten erreichbaren Tabelle, indiziert nach Tabellenname:

public static array $blacklistedColumns = [
    'user' => [
        'password', 'confirm_password', 'session',
        'remember_token', 'remember_token_expires',
        'confirmation_code', 'app_key',
    ],
    'customers'    => ['avatar'],
    'productlines' => ['image'],
];

Eine hier gelistete Spalte ist versteckt und vor Schreibzugriffen gesperrt - sie wird nie in einer Listen-/Formular-JSON-Antwort zurückgegeben und nie bei Insert/Update akzeptiert, unabhängig davon, was der eigene ->columns()-/->fields()-Aufruf einer Seite verlangt. Das ist es, was eine Tabelle wie user überhaupt sicher offenlegbar macht: Die Tabelle selbst muss nicht gesperrt werden, nur weil eine sensible Spalte darauf es sein muss.

$appSecret - Signierung, nicht Sperrung

Ein verwandtes, aber separates Anliegen: $appSecret signiert per HMAC ->where()-/->subselect()-/->pass_var()-Bedingungen sowie Logikbedingungs-Payloads, bevor sie durch den Browser reisen, damit ajax_crud.php sich weigern kann, einen Wert mit nicht passender Signatur anzuwenden. Es schützt die eigene, beabsichtigte Eingrenzung einer Seite (z. B. "nur die eigenen Bestellungen dieses Kunden anzeigen") davor, clientseitig manipuliert zu werden - es ersetzt nicht die oben beschriebene Tabellen-/Spalten-Blacklist. Wie Sie vor dem Launch einen starken Wert erzeugen, erfahren Sie unter Produktivbetrieb einrichten.