DEV Community: SecuriumAgency

Comment sécuriser et automatiser vos scripts PowerShell en entreprise

SecuriumAgency — Fri, 30 Oct 2026 14:35:34 +0000

Pourquoi l'exécution non contrôlée de scripts PowerShell est un risque

Dans les environnements Active Directory et Azure AD, l'automatisation via PowerShell est indispensable pour la gestion de parc et le nettoyage des caches système. Cependant, laisser des scripts non signés s'exécuter en tâches planifiées sans contrôle d'intégrité expose votre infrastructure à des élévations de privilèges et à des exécutions malveillantes.

Pour maintenir un niveau de sécurité maximal, l'application d'une politique d'exécution stricte couplée à une analyse automatique des logs d'exécution est essentielle dans toute stratégie SecOps moderne.

1. Configurer une ExecutionPolicy stricte

La première étape consiste à bloquer les scripts non approuvés au niveau des stratégies de groupe (GPO) ou via Microsoft Intune. L'utilisation du paramètre RemoteSigned ou AllSigned permet de garantir que seuls les scripts développés en interne ou signés par une autorité de confiance locale peuvent être lancés :

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine -Force

Les deux valeurs ne se valent pas. RemoteSigned n'exige une signature que pour les scripts marqués comme téléchargés depuis Internet : un script créé sur la machine s'exécute sans signature. AllSigned l'exige pour tous les scripts, y compris les vôtres. C'est la valeur à viser sur les serveurs et les postes d'administration.

Deux précisions évitent les mauvaises surprises :

La GPO a le dernier mot. Le paramètre « Activer l'exécution des scripts » (Turn on Script Execution), disponible aussi dans le catalogue de paramètres Intune, l'emporte sur le réglage local et sur l'option -ExecutionPolicy passée en ligne de commande. Get-ExecutionPolicy -List affiche la valeur retenue à chaque niveau.
Ce n'est pas une frontière de sécurité. Microsoft le précise dans sa documentation : l'ExecutionPolicy évite les exécutions accidentelles, elle n'arrête pas un utilisateur décidé, qui peut toujours coller le contenu d'un script dans une console. Pour interdire réellement le code non approuvé, il faut App Control for Business (ex-WDAC) ou AppLocker, qui font basculer PowerShell en mode de langage contraint.

2. Signer vos scripts avec un certificat de signature de code

Une politique AllSigned n'a de sens que si vos propres scripts sont signés. Le certificat vient de votre autorité de certification interne (modèle Code Signing d'AD CS) et il est déployé par GPO dans le magasin « Éditeurs approuvés » des postes. Sans cela, chaque exécution demande une confirmation, et une tâche planifiée, qui ne peut pas répondre, échoue.

$cert = Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert | Select-Object -First 1

$signature = @{
    FilePath        = '.\Clear-TempFiles.ps1'
    Certificate     = $cert
    HashAlgorithm   = 'SHA256'
    TimestampServer = 'http://timestamp.digicert.com'
}
Set-AuthenticodeSignature @signature

(Get-AuthenticodeSignature .\Clear-TempFiles.ps1).Status   # Valid

Trois détails comptent :

HashAlgorithm : Windows PowerShell 5.1 signe encore en SHA-1 par défaut.
TimestampServer : l'horodatage garde la signature valide après l'expiration du certificat. Sans lui, tous vos scripts cessent de s'exécuter ce jour-là.
La moindre modification du fichier, même un espace, fait passer le statut à HashMismatch et le script est refusé. C'est le contrôle d'intégrité recherché.

Signez dans votre pipeline plutôt que depuis un poste : la clé privée reste dans un coffre, et seul le code relu sur la branche principale reçoit une signature. Avant cette étape, le dépôt passe par les mêmes contrôles que n'importe quel code : analyse statique avec PSScriptAnalyzer (Invoke-ScriptAnalyzer -Path .\scripts -Recurse) et détection des secrets committés par erreur, l'une des cinq familles d'outils de notre trousse d'audit de sécurité.

3. Automatiser le nettoyage du disque sans casser les outils de développement

Le script de maintenance le plus répandu est aussi le plus dangereux : vider %TEMP% sans discernement. Sur un poste de développeur, ce dossier n'est pas qu'un cache. Claude Code y garde les répertoires de travail de ses sessions (%TEMP%\claude), et une purge en cours de session supprime ses fichiers de travail. Sa configuration et sa mémoire vivent dans %USERPROFILE%\.claude, les extensions de VS Code dans %USERPROFILE%\.vscode, ses données utilisateur dans %APPDATA%\Code.

Un nettoyage sûr repose sur trois règles : ne supprimer que les fichiers anciens, exclure explicitement les dossiers à préserver, et pouvoir simuler avant d'agir.

#Requires -Version 5.1
[CmdletBinding(SupportsShouldProcess)]
param(
    [int]$OlderThanDays = 7
)

# Dossiers à ne jamais purger : données de VS Code et de Claude Code.
# Get-Item les ramène à leur forme longue : $env:TEMP est souvent en nom
# court 8.3 (C:\Users\DUPONT~1\...), alors que Get-ChildItem renvoie le
# chemin long. Sans cette étape, la comparaison échoue et le dossier est purgé.
$protected = @(
    (Join-Path $env:TEMP        'claude'),
    (Join-Path $env:USERPROFILE '.claude'),
    (Join-Path $env:USERPROFILE '.vscode'),
    (Join-Path $env:APPDATA     'Code')
) | Where-Object { Test-Path -LiteralPath $_ } |
    ForEach-Object { (Get-Item -LiteralPath $_ -Force).FullName }

$limit = (Get-Date).AddDays(-$OlderThanDays)

Get-ChildItem -LiteralPath $env:TEMP -File -Recurse -Force -ErrorAction SilentlyContinue |
    Where-Object {
        $path = $_.FullName
        $_.LastWriteTime -lt $limit -and
        -not ($protected | Where-Object { $path.StartsWith("$_\", [StringComparison]::OrdinalIgnoreCase) })
    } |
    Remove-Item -Force -ErrorAction SilentlyContinue

SupportsShouldProcess apporte le paramètre -WhatIf : .\Clear-TempFiles.ps1 -WhatIf liste ce qui serait supprimé sans rien toucher. Les trois derniers dossiers de la liste ne sont pas sous %TEMP% ; ils sont là pour le jour où quelqu'un élargira la cible à AppData ou au profil entier.

Le piège est décrit dans le commentaire. Sur un poste dont le nom d'utilisateur dépasse huit caractères, $env:TEMP vaut souvent C:\Users\DUPONT~1\AppData\Local\Temp. Comparé tel quel aux chemins longs renvoyés par Get-ChildItem, il ne correspond à rien, et le dossier « protégé » est purgé. Nous l'avons constaté en testant ce script sur un dossier factice avant de le publier : c'est la meilleure raison de lancer -WhatIf avant le premier Remove-Item.

Avant de le planifier, appliquez-lui les règles de tout traitement sans surveillance : relançable sans dégât, code de sortie exploitable, journalisation, aucun secret en clair. Nous les détaillons dans notre note sur les scripts d'automatisation fiables.

4. Planifier l'exécution avec le moins de privilèges possible

Nettoyer son propre dossier temporaire ne demande aucun droit d'administration. La tâche s'exécute donc dans le contexte de l'utilisateur connecté, sans élévation, et non sous un compte de service à hauts privilèges :

$action = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument (
    '-NoProfile -NonInteractive -ExecutionPolicy AllSigned ' +
    '-File "C:\Program Files\Maintenance\Clear-TempFiles.ps1"'
)
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Friday -At 12:30

# S-1-5-32-545 : le groupe Utilisateurs, quelle que soit la langue de Windows.
$principal = New-ScheduledTaskPrincipal -GroupId 'S-1-5-32-545' -RunLevel Limited

Register-ScheduledTask -TaskName 'Nettoyage TEMP' -Action $action -Trigger $trigger -Principal $principal

Le script, lui, est stocké dans un dossier que seuls les administrateurs peuvent modifier : la signature protège son contenu, les droits NTFS protègent son emplacement. Si une tâche doit vraiment s'exécuter avec des privilèges élevés, préférez un compte de service administré de groupe (gMSA) à un compte dont le mot de passe n'expire jamais.

5. Journaliser et auditer chaque exécution

Signer dit qui a écrit le script ; journaliser dit ce qui s'est réellement exécuté. Activez par GPO la journalisation des blocs de script (Turn on PowerShell Script Block Logging) : chaque bloc exécuté est consigné sous l'identifiant 4104 dans le journal Microsoft-Windows-PowerShell/Operational, y compris le code décodé d'une commande passée en Base64.

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-PowerShell/Operational'
    Id      = 4104
} -MaxEvents 20 | Select-Object TimeCreated, Message

Centralisez ce journal dans votre SIEM, puis alertez sur ce qui n'a rien à faire dans une tâche de maintenance : un téléchargement suivi d'une exécution, du code décodé à la volée, un appel à Invoke-Expression sur du contenu distant. Complétez avec l'audit des créations de processus (événement 4688, ligne de commande incluse), qui montre les lancements en -ExecutionPolicy Bypass ou -EncodedCommand. C'est cette analyse automatique des journaux, plus que la politique d'exécution, qui révèle un script détourné.

Ce qu'il faut retenir

AllSigned déployée par GPO ou Intune, en sachant qu'elle prévient l'accident, pas l'attaque : le contrôle réel passe par App Control ou AppLocker.
Des scripts signés en SHA-256, horodatés, depuis le pipeline, après analyse statique et détection de secrets.
Un nettoyage qui ne supprime que l'ancien, exclut les dossiers de VS Code et de Claude Code, et se simule avec -WhatIf.
Des tâches planifiées sans privilège superflu, et des scripts stockés hors de portée des utilisateurs standards.
La journalisation des blocs de script centralisée et surveillée.

Ressources complémentaires

🔐 Sécurité : auditer, authentifier, durcir : nos notes sur l'audit et le durcissement.
⚙️ CI/CD : le pipeline minimal : les étapes à garder, et dans quel ordre, pour des mises en production réversibles.
🧪 Le Lab Securium : toutes nos notes techniques, classées par thématique.

Article rédigé avec l'aide d'une IA, relu et vérifié par l'auteur.

Secrets Next.js : 3 garde-fous PowerShell

SecuriumAgency — Tue, 13 Oct 2026 13:22:57 +0000

Un projet Next.js perd ses secrets par deux chemins que ni le typage, ni le linter, ni le build ne surveillent. Le premier est Git : une clé collée dans un fichier de test, un .env emporté par un git add ., et la valeur reste dans l'historique même si le commit suivant la supprime. Le second est le bundle : une valeur que le serveur devait garder pour lui part dans les fichiers servis à chaque visiteur.

Cet article met en place trois garde-fous, écrits en PowerShell pour tourner sur un poste Windows comme dans GitHub Actions : un hook pre-commit, un scan du bundle après next build, puis les deux contrôles rejoués en CI. Les deux scripts ont été testés sous Windows PowerShell 5.1, sur un dépôt jetable puis sur un faux build, et n'utilisent que des commandes communes à PowerShell 7.

Deux fuites, deux mécanismes

Dans Git, tout ce qui est committé est conservé. Supprimer la clé dans un second commit ne retire rien : elle reste lisible dans l'historique, dans chaque clone et dans chaque fork. Sur un dépôt public, des robots parcourent les nouveaux commits en continu. Sur un dépôt privé, elle est à la portée de toute personne et de toute intégration qui a un accès en lecture.

Dans le bundle, Next.js applique une règle simple : une variable préfixée NEXT_PUBLIC_ est copiée en clair dans le JavaScript au moment du build, les autres ne sont lisibles que par le serveur. Une clé d'API atteint donc le navigateur de quatre façons :

elle a reçu le préfixe NEXT_PUBLIC_ « pour que ça marche » dans un composant client ;
elle figure dans la clé env de next.config.js, qui la rend lisible par le code client quel que soit son nom ;
un Server Component la passe en prop à un composant client, et elle est sérialisée dans la page ;
elle est écrite en dur dans un module importé des deux côtés.

Le premier mécanisme se contrôle au moment du commit, le second après le build.

1. Bloquer le commit avec un hook PowerShell

Un hook pre-commit s'exécute avant l'enregistrement du commit et l'annule s'il se termine par un code de sortie non nul. Le script ci-dessous lit le diff de l'index et ne contrôle que les lignes ajoutées : un secret déjà présent dans le dépôt ne bloque pas le travail de l'équipe, il relève du scan d'historique abordé plus bas.

#Requires -Version 5.1
<#
.SYNOPSIS
    Bloque les secrets dans les lignes en attente de commit.
.EXAMPLE
    .\scripts\Test-GitSecrets.ps1                               # index : hook pre-commit
    .\scripts\Test-GitSecrets.ps1 -Range 'origin/main...HEAD'   # plage de commits : CI
#>
[CmdletBinding()]
param(
    [string]$Range
)

# Formats publics des fournisseurs, puis une règle générique.
$rules = [ordered]@{
    'bloc PRIVATE KEY'           = '-----BEGIN (?:RSA |EC |DSA |OPENSSH |PGP )?PRIVATE KEY'
    'identifiant AWS'            = '\b(?:AKIA|ASIA)[0-9A-Z]{16}\b'
    'jeton GitHub'               = '\b(?:gh[pousr]_[A-Za-z0-9]{36,}|github_pat_[A-Za-z0-9_]{22,})'
    'secret Stripe live'         = '\b[sr]k_live_[A-Za-z0-9]{24,}'
    'secret Anthropic ou OpenAI' = '\bsk-(?:ant|proj)-[A-Za-z0-9_-]{20,}'
    'jeton Slack'                = '\bxox[abprs]-[A-Za-z0-9-]{10,}'
    'secret en dur'              = '(?i)(?:api_?key|secret|token|password)\w*["'']?\s*[:=]\s*["''](?!https?://)[^"''\s]{16,}["'']'
}
# .env, .env.local, .env.production... mais pas .env.example.
$envFile     = '(^|/)\.env(\.[^/]*)?$'
$envTemplate = '\.(example|sample|template)$'

$scope = if ($Range) { $Range } else { '--cached' }
$diff  = git diff $scope --unified=0 --no-color --diff-filter=ACMR
if ($LASTEXITCODE -ne 0) {
    Write-Warning "Erreur de git diff ($scope) : scan impossible."
    exit 2
}

$findings = @()
$file     = ''
$line     = 0
$inHunk   = $false

foreach ($text in $diff) {
    if ($text -match '^diff --git ') { $inHunk = $false; continue }
    if ($text -match '^@@ -\S+ \+(\d+)') { $inHunk = $true; $line = [int]$Matches[1]; continue }
    if (-not $inHunk) {
        # En-tête du fichier : son nom précède le premier bloc @@.
        if ($text -match '^\+\+\+ "?b/(.+?)"?$') {
            $file = $Matches[1]
            if ($file -match $envFile -and $file -notmatch $envTemplate) {
                $findings += "${file} : fichier .env"
            }
        }
        continue
    }
    if ($text -notmatch '^\+') { continue }

    if ($text -notmatch 'secret-scan:allow') {
        foreach ($rule in $rules.GetEnumerator()) {
            if ($text -cmatch $rule.Value) { $findings += "${file}:${line} : $($rule.Key)" }
        }
    }
    $line++
}

if ($findings.Count -gt 0) {
    $findings | ForEach-Object { Write-Warning $_ }
    Write-Warning 'Secret dans le diff. Retirez-le, ou signalez un faux positif avec secret-scan:allow.'
    exit 1
}

Trois choix à connaître avant de l'adopter :

-cmatch, pas -match. L'opérateur -match ignore la casse, alors que les formats des fournisseurs y sont sensibles : une comparaison insensible multiplie les faux positifs.
Le rapport ne contient jamais la valeur. Fichier, ligne, règle : c'est suffisant pour corriger, et le journal de CI ne devient pas une seconde fuite.
Les messages sont sans accents. Windows PowerShell 5.1 lit en ANSI un fichier UTF-8 sans BOM, et les caractères accentués d'un message sortiraient déformés.

La règle générique (« secret en dur ») fait du bruit par nature. Un faux positif se lève en ajoutant le commentaire secret-scan:allow sur la ligne, ce qui laisse une trace relisible en revue de code. À l'inverse, aucune liste de formats n'est complète : ajoutez ceux de vos fournisseurs.

Git ne versionne pas .git/hooks. Le hook vit donc dans un dossier du dépôt, .githooks/pre-commit :

#!/bin/sh
# PowerShell 7 s'il est installé (Windows, Linux, macOS), sinon Windows PowerShell 5.1.
if command -v pwsh >/dev/null 2>&1; then ps=pwsh; else ps=powershell.exe; fi
exec "$ps" -NoProfile -NonInteractive -File scripts/Test-GitSecrets.ps1

À sa création, une commande enregistre son bit d'exécution dans l'index : Windows s'en passe, mais Linux et macOS ignorent un hook qui ne l'a pas. Ensuite, chaque clone active le dossier une fois.

git add --chmod=+x .githooks/pre-commit   # une fois, par l'auteur du hook
git config core.hooksPath .githooks       # une fois par clone

Si la politique d'exécution du poste interdit les scripts, le hook échoue et le commit avec lui. RemoteSigned suffit pour un script cloné ; sous AllSigned, il doit être signé comme n'importe quel script d'entreprise, ce que détaille notre guide sur la signature des scripts PowerShell.

2. Vérifier ce que le navigateur reçoit

Le hook ne voit pas le second chemin. Une variable mal préfixée vit dans un .env.local que Git ignore, et c'est le build qui la publie. Le contrôle porte donc sur la sortie du build, et il compare des valeurs : pour chaque variable sensible du serveur, le script cherche sa valeur exacte dans les fichiers que Next.js enverra au navigateur.

#Requires -Version 5.1
<#
.SYNOPSIS
    Cherche les secrets du serveur dans les fichiers servis au navigateur.
.EXAMPLE
    npm run build; .\scripts\Test-BundleSecrets.ps1
#>
[CmdletBinding()]
param(
    [string]$BuildDir  = '.next',
    [string]$Sensitive = 'KEY|SECRET|TOKEN|PASSWORD|DATABASE_URL'
)

if (-not (Test-Path -LiteralPath "$BuildDir/static")) {
    Write-Warning "Aucun build dans $BuildDir : lancez next build avant le scan."
    exit 2
}

# Variables du processus (CI), puis des fichiers .env* du poste, hors modèles.
$assignment = '^\s*(?:export\s+)?([A-Za-z_]\w*)\s*=\s*(?:"([^"]*)"|''([^'']*)''|([^#\s]*))'
$vars = @(
    Get-ChildItem Env:
    Get-ChildItem -Path . -Filter '.env*' -File -Force |
        Where-Object { $_.Name -notmatch '\.(example|sample|template)$' } |
        Get-Content |
        ForEach-Object {
            if ($_ -match $assignment) {
                [pscustomobject]@{ Name = $Matches[1]; Value = "$($Matches[2])$($Matches[3])$($Matches[4])" }
            }
        }
)

$public  = @($vars | Where-Object { $_.Name -like 'NEXT_PUBLIC_*' })
$secrets = @($vars |
    Where-Object { $_.Name -notlike 'NEXT_PUBLIC_*' -and $_.Name -match $Sensitive -and $_.Value.Length -ge 16 } |
    Sort-Object Name, Value -Unique)
if ($secrets.Count -eq 0) {
    Write-Warning 'Aucune variable sensible en vue : scan sans objet.'
    exit 2
}

# Ce que le navigateur reçoit : chunks JS et CSS, puis HTML et charges RSC des pages prérendues.
$served = @(
    Get-ChildItem -Path "$BuildDir/static" -Recurse -File
    Get-ChildItem -Path "$BuildDir/server/app" -Recurse -File -ErrorAction SilentlyContinue |
        Where-Object { $_.Extension -in '.html', '.rsc', '.body' }
)

$leaks = 0
foreach ($var in $public) {
    if ($var.Name -match 'SECRET|PASSWORD|PRIVATE') {
        Write-Warning "$($var.Name) : variable publique au nom de secret"
        $leaks++
    }
}
foreach ($secret in $secrets) {
    $hit = $served |
        Select-String -SimpleMatch -CaseSensitive -Pattern $secret.Value -List |
        Select-Object -First 1
    if ($hit) {
        Write-Warning "$($secret.Name) : valeur servie au navigateur ($($hit.Path))"
        $leaks++
    }
}

if ($leaks -gt 0) { exit 1 }
Write-Output "$($secrets.Count) valeurs sensibles, $($served.Count) fichiers servis : aucune fuite."

La comparaison par valeur ne s'intéresse pas à la cause. Une clé recopiée dans une variable publique, inscrite dans next.config.js, passée en prop ou écrite en dur : dans tous les cas, la valeur d'une variable du serveur se retrouve dans un fichier servi, et le script la signale sans jamais l'afficher. S'il ne trouve aucune variable à comparer, il sort en erreur : un contrôle qui ne compare rien ne doit pas passer pour un contrôle réussi.

Il reste un angle mort. Un secret qui n'existe que sous un nom public anodin, NEXT_PUBLIC_OPENAI_API_KEY par exemple, ne ressemble à rien de suspect pour le script. Toute nouvelle variable NEXT_PUBLIC_ mérite donc une question en revue de code : cette valeur peut-elle être lue par n'importe qui ?

En amont, un module réservé au serveur évite la plupart des accidents. Le paquet server-only (npm install server-only) fait échouer le build dès qu'un composant client importe le fichier :

// lib/env.server.ts
import "server-only";

function required(name: string): string {
  const value = process.env[name];
  if (!value) throw new Error(`Variable d'environnement manquante : ${name}`);
  return value;
}

/** Secrets du serveur, lus à l'usage et jamais au chargement du module. */
export const serverEnv = {
  get stripeSecretKey() {
    return required("STRIPE_SECRET_KEY");
  },
  get resendApiKey() {
    return required("RESEND_API_KEY");
  },
};

Les accesseurs diffèrent la lecture : une variable absente lève une erreur à la première utilisation, avec son nom, plutôt qu'un undefined qui voyage jusqu'à l'appel d'API.

3. Rejouer les deux contrôles en CI

Un hook est local, facultatif et contournable : git commit --no-verify l'ignore, et un clone neuf ne l'a pas encore activé. Il réduit les accidents, il ne garantit rien. La garantie vient du pipeline, qui relance les mêmes scripts sur chaque pull request :

name: Secrets

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  scan:
    runs-on: ubuntu-latest
    # Valeurs canari, vues par le build comme par le scan : aucun secret réel.
    env:
      STRIPE_SECRET_KEY: canari-stripe-secret-key-0001
      RESEND_API_KEY: canari-resend-api-key-0002
    steps:
      - uses: actions/checkout@v5
        with:
          fetch-depth: 0

      - name: Secrets dans les commits
        shell: pwsh
        env:
          BASE: ${{ github.event.pull_request.base.sha || github.event.before }}
        run: ./scripts/Test-GitSecrets.ps1 -Range "${env:BASE}...HEAD"

      - uses: actions/setup-node@v5
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run build

      - name: Secrets dans le bundle
        shell: pwsh
        run: ./scripts/Test-BundleSecrets.ps1

Quatre détails font la différence :

Des valeurs canari, pas les vrais secrets. Le scan compare des valeurs : il lui suffit que chaque variable du serveur en porte une, reconnaissable. Le job fonctionne donc aussi sur la pull request d'un fork, à laquelle GitHub ne transmet aucun secret du dépôt. Si votre build interroge une base ou une API, seules ces variables-là restent de vrais secrets.
La base de comparaison passe par env. Une expression de contexte écrite directement dans un bloc run est collée dans le script avant son exécution : c'est le vecteur classique d'injection dans un workflow.
permissions: contents: read. Le job lit le dépôt et rien d'autre.
fetch-depth: 0. Sans historique, la base de comparaison n'existe pas et git diff échoue. Le script sort alors en code 2 au lieu de déclarer le diff propre.

Ces réglages relèvent d'un principe plus large, celui d'un pipeline qui reste court et dont chaque étape a les droits minimaux : nous le détaillons dans notre note sur le pipeline CI/CD minimal.

Si le secret est déjà parti

Les deux scripts regardent ce qui arrive, pas ce qui est déjà là. Pour l'historique existant, passez un détecteur de secrets dédié (gitleaks, TruffleHog) sur le dépôt complet, et activez la push protection de GitHub, gratuite sur les dépôts publics. C'est l'une des cinq familles d'outils de notre trousse d'audit de sécurité.

Quand un secret a été poussé, l'ordre des opérations compte :

Révoquer et remplacer la clé chez le fournisseur, tout de suite. C'est la seule action qui annule la fuite.
Lire les journaux du fournisseur sur la période d'exposition, pour savoir si la clé a servi.
Nettoyer l'historique ensuite, si nécessaire, avec git filter-repo. C'est de l'hygiène, pas une remédiation : les clones, les forks et les caches gardent l'ancienne version.

Ce qu'il faut retenir

Un secret fuit par Git ou par le bundle, et chaque chemin a son contrôle : le diff au commit, les fichiers servis après le build.
Le hook pre-commit ne lit que les lignes ajoutées, ne révèle jamais la valeur et se contourne : il évite l'accident, pas la négligence.
Le scan du bundle compare des valeurs, ce qui couvre le préfixe recopié, next.config.js, les props et le code en dur.
La CI rejoue les deux scripts avec des valeurs canari, sans secret réel et avec des droits en lecture seule.
Une clé poussée se révoque d'abord. L'historique se nettoie après.

Un site ou une application Next.js à concevoir, à refondre ou à optimiser ? Découvrez les services de Securium Agency, ou présentez-nous votre projet.

Article rédigé avec l'aide d'une IA, relu et vérifié par l'auteur.

Les secrets d'un tunnel de conversion B2B automatisé via Webhooks

SecuriumAgency — Mon, 12 Oct 2026 19:51:15 +0000

Le tunnel de conversion classique a un trou : tu apprends qu'un lead a cliqué,
ou qu'une vente est passée, des heures plus tard — en consultant un tableau de
bord que tu as oublié d'ouvrir. Les webhooks ferment ce trou. Voici les trois
qui comptent, et comment les sécuriser.

Webhook 1 — le signal de clic

L'utilisateur tape sur un CTA de paiement. Avant même la redirection, le client
envoie un signal :

fetch("/api/track-click", {
  method: "POST",
  keepalive: true, // la requête survit à la navigation
  body: JSON.stringify({ offer, price }),
});
window.location.href = checkoutUrl; // redirection immédiate

keepalive est la clé : la requête part, la redirection se fait dans la
foulée, zéro friction pour l'acheteur. Côté serveur, un Route Handler pousse
un embed Discord (ou Slack). Tu es notifié en temps réel, sans dashboard.

Webhook 2 — la confirmation de paiement

Le prestataire (Stripe, Revolut…) appelle ton endpoint quand la commande est
complète. Ne fais jamais confiance au payload brut.

const raw = await request.text(); // corps BRUT, avant JSON.parse
const expected = hmacSha256(secret, `${timestamp}.${raw}`);
if (!timingSafeEqual(signature, expected)) return new Response(null, { status: 401 });

Vérifie la signature HMAC sur le corps brut, avec une fenêtre anti-rejeu (rejette
un événement daté de plus de 5 minutes). Sans ça, n'importe qui peut simuler une
vente.

Webhook 3 — la livraison

Sur order.completed, tu déclenches la livraison : génération d'un magic link
(JWT signé, expirant), envoi d'un e-mail transactionnel, ouverture d'un accès.
Tout ça sans intervention humaine.

Les deux pièges à éviter

L'idempotence. Un webhook est rejoué (timeout réseau, retry du prestataire). Déduplique sur l'order_id avant d'envoyer un e-mail ou de créer un accès — sinon le client reçoit trois fois sa commande.
Les endpoints publics. /api/track-click n'a pas de secret partagé : il est exposé. Valide strictement l'entrée (n'accepte que les couples offre/prix connus), limite le débit, et ne fais rien de coûteux si l'entrée est douteuse.

Le pattern « thin webhook »

Un endpoint de webhook a un budget de temps serré : le prestataire considère
l'appel échoué s'il n'a pas de réponse en quelques secondes, et il rejoue. La
règle : acquitter vite, traiter après. Vérifie la signature, écris
l'événement quelque part (file, log structuré), renvoie 200, et laisse le
traitement lourd (e-mail, appel API tiers) se faire hors du cycle
requête/réponse. Sur Vercel, waitUntil() prolonge la fonction après la
réponse ; sinon, une file légère fait l'affaire.

Pour le debug : tous les prestataires sérieux fournissent un rejeu manuel des
événements et un historique des tentatives. Regarde-le avant de soupçonner ton
code.

Le résultat

Un tunnel où chaque étape se déclenche toute seule : clic → notif temps réel,
paiement → livraison automatique, le tout tracé. Tu n'ouvres un outil que quand
il y a une décision humaine à prendre. Le reste tourne.

🎯 Le tunnel automatisé, packagé : l'écosystème Securium Labs

⚡ Boilerplate Next.js Ultime — 149 € — Route Handlers de tracking et de webhook (signature HMAC, idempotence) déjà en place.
🧠 Pack Prompts & Workflows IA — 39 € — les workflows de qualification et de relance qui alimentent le tunnel.
⚙️ Setup Machine B2B — 490 € — le tunnel complet déployé sur ton infrastructure, livré en 48 h.

→ www.securium-labs.app/offres