Ruby on Rails
Rails abstrait beaucoup. Les pièges, eux, sont précis.
Un strong params oublié, un where interpolé à la main,
un secret_key_base faible, un YAML.load sur une entrée utilisateur : les failles Rails se nichent
dans des endroits connus. Je vais droit à ces endroits au lieu de balayer au hasard.
Ce que couvre l'audit Rails.
Les classes de failles les plus fréquentes sur une application Rails réelle, testées à la main sur votre code et vos endpoints. OWASP WSTG + API Top 10, en authentifié comme en non authentifié.
where interpolé, find_by_sql, ordre/condition non bornésYAML.load, Marshal, cookies signés, secret_key_baserender inline, ERB sur entrée utilisateur, open redirectQuatre étapes. Prix et périmètre fixes.
De la prise de contact à l'attestation, votre audit Rails suit une séquence claire — pas un tunnel. Vous savez toujours où vous en êtes, ce qui a été trouvé et ce qu'il reste. Prix fixe défini au cadrage.
Cadrage
Un court appel, un prix fixe, des règles d'engagement écrites. La version de Rails et le périmètre sont notés ici.
~ 1 appelTest
Test manuel sur les cibles convenues, canal ouvert en direct. Le critique est signalé le jour où je le trouve.
5–10 joursRapport
Chaque faille : criticité, reproduction, impact réel, correctif concret. Plus une synthèse pour vos clients.
2–3 joursContre-test
Vous corrigez, je vérifie et délivre une attestation propre. Inclus, pas une prestation à part.
gratuit · 30 jQuand ce test devient urgent.
Un pentest n'attend pas l'incident. Voici les déclencheurs les plus fréquents chez les équipes Rails qui me contactent.
- Un client grand compte exige une preuve de test avant de signer
- Une revue SOC 2 / ISO 27001 réclame un pentest annuel
- Une levée de fonds et sa due diligence technique approchent
- Une montée de version Rails ou une refonte change la surface d'attaque
- Une première mise en production d'une app qui manipule des données sensibles
- Un doute sur Devise, Pundit ou une logique de permissions
Ce qu'on me demande avant de signer.
Les vraies questions d'un premier appel de cadrage sur une application Rails. Si la vôtre manque, elle a sa réponse en un e-mail.
Quelles versions de Rails testez-vous ?
De Rails 4 aux dernières, en API-only comme en monolithe avec vues. La version exacte est notée au cadrage.
Avez-vous besoin du code source ?
Pas obligatoire. En boîte grise (accès au code) le test va plus loin, surtout sur le mass assignment et les autorisations.
Testez-vous les gems tierces ?
Oui. Devise, Pundit, CanCanCan, Sidekiq et les dépendances exposées font partie de la surface d'attaque.
Sur prod ou sur staging ?
Staging iso-prod de préférence, avec des données réalistes. La prod reste possible avec des règles d'engagement écrites.
Comment fixez-vous le prix ?
Forfait fixe défini au cadrage, à partir du périmètre. Pas de facturation à l'heure, pas de dépassement surprise. Vous validez le prix avant que je commence.
Que se passe-t-il une fois les correctifs faits ?
Contre-test inclus, gratuit, sous 30 jours. Je revérifie chaque faille corrigée et délivre une attestation à jour, prête pour vos clients.
Qui mène votre test.
Les certifications ne trouvent pas les failles. L'attention méthodique, si. C'est ce que vous payez vraiment.
Saïd Mimouni
Pentest & audit de sécurité · applications web & API
Je teste des applications web et des API à la main, aujourd'hui en solo pour des startups et des agences. Vous parlez à la personne qui ouvre le terminal, du premier e-mail au contre-test.
Je suis aussi le fondateur d'auditdude.com, un audit de code en boîte blanche : même regard sécurité, côté source. Ici, c'est du test manuel en boîte noire, mené par moi.
Une app Rails à mettre à l'épreuve ?
Dites-moi la version de Rails, le périmètre et à peu près quand vous en avez besoin. Vous recevrez un périmètre et un prix fixe en retour, souvent le jour même.