Audit du code qu'on vient de récupérer — par où commencer pour une revue de code OWASP Top 10 ?

Pour la recherche manuelle, un grep ciblé fonctionne super bien : 1) Les appels BDD avec concaténation directe de variables, 2) Les clés secrètes laissées en clair dans le code, 3) Les blocs catch qui renvoient des infos système sensibles au client. Traquer ces patterns ne prend que quelques heures.

Quand on a repris un portail de taille similaire, on a trouvé 5 failles d'élévation de privilèges en deux jours de revue manuelle. Les scanners auto n'avaient rien vu du tout parce que seul un humain qui lit la logique métier peut savoir quelle donnée doit être visible par qui.

Commencez par auditer les dépendances tierces du projet. Lancez les commandes d'audit de sécurité natives de votre gestionnaire de paquets et mettez à jour les packages vulnérables. Souvent les plus grosses failles laissées par les agences viennent simplement de librairies périmées.

Pour deux développeurs qui n'ont pas écrit le code, sécuriser l'architecture d'un tiers juste avec la checklist OWASP, c'est super difficile. Si le temps presse, concentrez-vous uniquement sur les droits d'accès et les requêtes BDD, ne perdez pas de temps avec les détails cryptographiques complexes.

regardez surtout si en changeant les id dans l'url vous pouvez voir les commandes des autres en général les agences oublient ce genre de vérif côté backend

edit : j'ai corrigé quelques fautes de frappe.

Au moment de signer avec de gros clients logistiques, il est très courant qu'ils exigent un rapport d'audit de sécurité indépendant. Votre revue en interne va fiabiliser la plateforme, mais elle n'aura pas la même valeur contractuelle qu'un audit externe.

Votre système est-il multi-tenant ? Tous les clients partagent-ils la même base de données ? Si oui, le point le plus critique de votre revue doit être le cloisonnement des données pour garantir qu'un client ne puisse jamais accéder aux enregistrements d'un autre.

Même si ça semble intimidant pour une petite équipe, utiliser le guide OWASP comme checklist fait monter les devs en compétences de façon incroyable. Plus vous corrigerez de failles métier, plus votre architecture globale deviendra robuste.

La solution qui semble bon marché finit souvent par coûter cher. Le fait que la sauvegarde soit accessible sur le même réseau et avec la même identité en fait une cible potentielle.

Sujet très actuel. Si vous ne formalisez pas cela par écrit dès le départ, des disputes éclateront plus tard.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Je suis d'accord en partie, pas en partie. La plupart des pertes de temps s'accumulent sur les tâches en attente de validation.

Je vais résumer ce qui a été dit jusqu'ici. L'erreur commise du côté de owasp top 10 revue de code est généralement réversible, mais coûteuse.

Je le note au cas où.

Il y a un point que je ne comprends pas. Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement.

Ce que tout le monde fait ne signifie pas que c'est la bonne chose. Bon courage.

Il y a un piège ici je ne pouvais pas ne pas le mentionner. Les gens défendent l'habitude, pas le processus. La résistance vient de là.

C'est confirmé par l'expérience.

Je parle du point de vue du fournisseur, c'est mon côté. Ne comptez pas sur une seule mesure de sécurité ; allez par couches.

Essayer de faire cela seul est la voie la plus coûteuse. À votre place, j'irais par cette voie.

enregistré.

C'est globalement vrai mais il manque un point. bref avant de décider regardez quelles données vous avez en main.

Si vous écrivez le résultat ici cela aidera aussi d'autres personnes.

C'est exactement ça. Ce qui nous faisait perdre le plus de temps, c'était l'absence de clarté sur qui prenait les décisions.

Essayer de faire cela seul est la voie la plus coûteuse.