Sécurité : liste noire des tables & colonnes

->columns() n'est pas une frontière de sécurité

Appeler ->columns('name', 'email') sur une page ne change que ce que la grille propre à cette page affiche. Cela n'a aucun effet sur core/ajax_crud.php, le point d'entrée REST auquel le JavaScript de chaque widget parle réellement - l'API résout la configuration d'une page en réexécutant sa route (xcrud_load_hooks_from_page()), mais les colonnes qu'une véritable table de base de données expose sont régies par le propre schéma de la table, pas par ce qu'une page a choisi d'afficher. Un visiteur qui appelle l'API directement (ouvrir DevTools, rejouer la requête avec une route/requête différente) n'est pas restreint par le rétrécissement ->columns() propre à une page.

Autrement dit : ->columns() est une commodité d'affichage. Ce n'est jamais ce qui se tient entre une colonne sensible et le réseau.

$blacklistedTables - la véritable frontière des tables

Chaque véritable table de la base de données connectée est accessible via Xcrud par défaut (introspectée en direct, rien à enregistrer au préalable) - $blacklistedTables dans src/Config.php est ce qui retire complètement une table de portée, quoi que le propre PHP d'une page essaie :

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

Une table sur liste noire ne peut jamais être atteinte via ->table(), comme cible de ->relation(), ou comme table enfant ->gallery() - appeler ->table('logs') lève immédiatement une exception plutôt que d'afficher silencieusement une grille vide.

$blacklistedColumns - blocage au niveau des colonnes

Certaines tables peuvent être exposées sans problème en général mais ont des colonnes spécifiques qui ne devraient jamais transiter par l'API - un hachage de mot de passe, un jeton interne, une colonne blob héritée. $blacklistedColumns bloque ces colonnes au sein d'une table par ailleurs accessible, indexée par nom de table :

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

Une colonne listée ici est cachée et bloquée en écriture - elle n'est jamais renvoyée dans une réponse JSON de liste/formulaire et jamais acceptée à l'insertion/mise à jour, quoi que demande le propre appel ->columns()/->fields() d'une page. C'est ce qui rend réellement une table comme user sûre à exposer du tout : la table elle-même n'a pas besoin d'être mise sur liste noire simplement parce qu'une de ses colonnes sensibles l'est.

$appSecret - signature, pas mise sur liste noire

Une préoccupation liée mais distincte : $appSecret signe par HMAC les conditions ->where()/->subselect()/->pass_var() et les charges utiles de conditions logiques avant qu'elles ne transitent par le navigateur, afin que ajax_crud.php puisse refuser d'en appliquer une dont la signature ne correspond pas. Cela protège le propre périmètre intentionnel d'une page (par exemple « n'afficher que les propres commandes de ce client ») contre toute altération côté client - cela ne remplace pas la liste noire de tables/colonnes ci-dessus. Voyez Déployer en production pour générer une valeur robuste avant le lancement.