Règle
Éviter SELECT * en SQL dans les requêtes SQL.
SELECT * dans production code fait applications
fragiles à schéma schémas et obscurcit données dépendances.

Langues prises en charge : 45+

Introduction

Utilisation SELECT * les requêtes en production récupèrent toutes les colonnes d'une table, y compris les colonnes que votre application n'utilise pas. Lorsque les schémas de base de données évoluent et que de nouvelles colonnes sont ajoutées (y compris des données sensibles comme des mots de passe ou des PII), les requêtes utilisant SELECT * les récupérer automatiquement sans modification de code. Cela crée des vulnérabilités de sécurité et rompt les hypothèses de votre logique d'application.

Pourquoi c'est important

Impact sur les performances : La récupération de colonnes inutiles augmente le temps d'exécution des requêtes, la taille des transferts réseau et la consommation de mémoire. Une table de 50 colonnes où vous n'en avez besoin que de 5 signifie que vous transférez 10 fois plus de données que nécessaire, dégradant les temps de réponse et augmentant les coûts d'infrastructure.

Implications en matière de sécurité : Les nouvelles colonnes ajoutées aux tables (champs d'audit, indicateurs internes, données utilisateur sensibles) sont automatiquement exposées via SELECT * requêtes. Votre API pourrait commencer à divulguer des hachages de mots de passe, des SSN ou des données commerciales internes qui n'étaient jamais destinées à ce point d'accès.

Maintenabilité du code : Quand SELECT * les requêtes échouent après des modifications de schéma ; la défaillance se produit à l'exécution (runtime), et non à la compilation (compile time). Une nouvelle colonne non-nullable ou un champ renommé provoque des erreurs en production. Les listes de colonnes explicites clarifient les dépendances et interrompent les builds lorsque les schémas changent de manière incompatible.

Exemples de code

❌ Non conforme :

async function getUserProfile(userId) {
    const query = 'SELECT * FROM users WHERE id = ?';
    const [user] = await db.execute(query, [userId]);

    return {
        name: user.name,
        email: user.email,
        createdAt: user.created_at
    };
}

Pourquoi c'est incorrect : Ceci récupère toutes les colonnes, y compris des champs potentiellement sensibles comme password_hash, ssn, internal_notes ou deleted_at. À mesure que le schéma évolue, cette requête devient plus lente et expose davantage de données, alors que l'application n'utilise que trois champs.

✅ Conforme :

async function getUserProfile(userId) {
    const query = `
        SELECT name, email, created_at
        FROM users
        WHERE id = ?
    `;
    const [user] = await db.execute(query, [userId]);

    return {
        name: user.name,
        email: user.email,
        createdAt: user.created_at
    };
}

Conclusion

Spécifiez toujours des listes de colonnes explicites dans les requêtes SQL. Cela prévient les fuites de données, améliore les performances et clarifie les dépendances entre le code et le schéma. Le faible coût initial de la saisie des noms de colonnes évite des catégories entières de problèmes de sécurité et de performance.