Pre-launch review.
A targeted security review of a WordPress site about to go live.
Missions acceptées
Pourquoi c'est un service à part
Pre-launch checks.
A pre-launch site has a different threat profile than a mature one. The development team has been moving fast. Staging credentials are everywhere. The "I'll clean up after launch" list is long. Admin accounts that should have been removed weeks ago are still there.
Nous avons vu beaucoup de sites se faire compromettre dans leur premier mois — pas par des attaquants sophistiqués, mais par des restes du processus de construction. Cette revue est conçue pour les attraper avant que le site soit indexé publiquement.
Qui réserve cela
- Agences remettant un site à un client et voulant un second regard d'abord.
- Équipes internes sur le point de migrer d'un environnement de staging vers la production.
- Clients recevant un site terminé qui veulent vérifier ce qu'ils héritent.
- Toute personne qui migre depuis Squarespace, Wix ou un autre CMS vers WordPress.
La checklist de lancement
Ce que nous collectons
Dev / agency / contractor accounts that shouldn't ship to production. The classic "admin / password123" still set up for testing.
Ancien staging.example.com ou example.com.staging.host toujours public, indexé et servant une copie non patchée du même site.
WP_DEBUG laissé activé. /wp-admin/install.php accessible. /debug.php ou autres scripts ponctuels commités par accident.
.env, .git, README.md, logs de déploiement ou fichiers de backup (sql, zip) accessibles à une URL.
Sample posts, Hello World, the default "admin" user, Akismet placeholder, sample plugin pages still public.
Formulaires de contact sans anti-spam, pages de connexion sans protection contre la brute-force, formulaires de commentaire sans CAPTCHA ni hashcash.
Plugins installés-mais-désactivés (toujours sur le disque, toujours attaquables). Versions d'essai, canaux beta, plugins issus de sources douteuses.
Verrouillage de l'édition de fichiers, XML-RPC, énumération d'utilisateurs via REST API, salts, flags de cookies sécurisés, HSTS, en-têtes de sécurité — tous vérifiés par rapport aux bonnes pratiques actuelles.
"Discourage search engines" left on, or off when it shouldn't be. robots.txt, sitemap.xml, canonical URLs all sanity-checked.
Calendrier
Quand réserver.
Idéal
Deux semaines avant le lancement
Largement le temps de corriger les constats sans retarder le lancement. Nous pouvons faire une passe de retest avant la mise en production.
Correct
Une semaine avant
Encore assez de marge pour les correctifs. Le retest dépend de l'ampleur des constats.
Serré
Dans les 48 heures
Créneau express — possible mais facturé différemment. Cela vaut quand même la peine : détecter un problème critique évite un incident bien pire une semaine plus tard.
Questions fréquentes
Questions fréquentes.
Est-ce un audit de sécurité complet ?
No — it's focused. A full audit covers more ground, including process and configuration depth. The pre-launch review targets the specific failure modes of a new-site launch.
Pouvez-vous aussi faire les correctifs ?
Les constats sont rédigés pour que votre développeur ou agence puisse agir dessus. Pour les clients agence, nous pouvons aussi pousser des petits correctifs nous-mêmes si vous préférez — facturé en sus de la revue.
Et si vous ne trouvez rien de sérieux ?
Great. The report still documents what I checked, with a "ready to launch" verdict. Useful for client handover and for the agency's own records.
Pouvons-nous faire ça chaque année ?
Pas vraiment — une fois lancé, le profil de menace change. Après le lancement, la bonne cadence est un audit de sécurité par an, plus un pentest après chaque changement majeur.
E-mail [email protected] or use the contact form.