Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
2 changes: 1 addition & 1 deletion docs/index.mdx → docs/en/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ import { Aside } from '@/components/docs'

Welcome to VulnAPI Documentation!

![Demo](../demo.gif)
![Demo](../../demo.gif)

---

Expand Down
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
1 change: 1 addition & 0 deletions docs/fr/best-practices/_meta.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
label: Bonnes pratiques
100 changes: 100 additions & 0 deletions docs/fr/best-practices/jwt.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,100 @@
---
title: Bonnes pratiques de sécurité JWT
description: Bonnes pratiques pour implémenter de manière sécurisée les JSON Web Tokens (JWT) dans vos API.
---

Les JSON Web Tokens (JWT) sont largement utilisés pour l'authentification et l'autorisation dans les API. Lorsqu'ils sont mal implémentés, ils deviennent une surface d'attaque à haute sévérité. Ce guide présente les meilleures pratiques les plus importantes et associe chaque point à l'analyse VulnAPI correspondante.

## Utiliser des algorithmes de signature forts

Privilégiez les algorithmes asymétriques (RS256, ES256) pour les systèmes distribués où plusieurs services vérifient les jetons mais un seul les émet. Cela garantit que la clé privée ne quitte jamais l'émetteur.

- **Recommandé** : RS256, RS384, RS512, ES256, ES384
- **Acceptable pour les systèmes à service unique** : HS256, HS384, HS512 (avec un secret fort — voir ci-dessous)
- **À ne jamais utiliser** : `alg: none` en production

L'utilisation de `alg: none` supprime toute protection cryptographique, rendant les jetons facilement falsifiables. VulnAPI détecte cela avec l'analyse [`jwt.alg_none`](../vulnerabilities/broken-authentication/jwt-alg-none).

## Utiliser un secret aléatoire d'au moins 256 bits pour HMAC

Lors de l'utilisation d'algorithmes HMAC (HS256/HS384/HS512), la clé secrète doit être :

- Au moins 256 bits (32 octets) de données cryptographiquement aléatoires
- Pas un mot du dictionnaire, un défaut bien connu ou une chaîne prévisible
- Pas une chaîne vide

Les jetons signés avec des secrets vides ou faibles sont détectés par les analyses [`jwt.blank_secret`](../vulnerabilities/broken-authentication/jwt-blank-secret) et [`jwt.weak_secret`](../vulnerabilities/broken-authentication/jwt-weak-secret).

```bash
# Générer un secret sécurisé de 256 bits (Linux/macOS)
openssl rand -base64 32
```

## Toujours vérifier les signatures côté serveur

Ne faites jamais confiance à un JWT sans vérifier sa signature à l'aide de la clé appropriée. L'omission de la vérification des signatures est l'une des erreurs d'implémentation les plus dangereuses.

VulnAPI détecte cela avec l'analyse [`jwt.not_verified`](../vulnerabilities/broken-authentication/jwt-not-verified) (CVSS 9.3).

```python
# Exemple Python avec PyJWT — passez toujours explicitement les algorithmes
import jwt
payload = jwt.decode(token, public_key, algorithms=["RS256"])
```

## Rejeter les jetons avec une signature supprimée

Certaines bibliothèques JWT acceptent des jetons dont le segment de signature est vide (signature nulle). Configurez toujours votre bibliothèque pour exiger une signature valide et non vide.

VulnAPI détecte cela avec l'analyse [`jwt.null_signature`](../vulnerabilities/broken-authentication/jwt-null-signature).

## Valider les revendications standards (Claims)

Après avoir vérifié la signature, valisez ces revendications avant de faire confiance aux données de la charge utile (payload) :

| Revendication | Description | Action |
|---------------|-------------|--------|
| `iss` | Émetteur (Issuer) — qui a créé le jeton | Rejeter s'il ne provient pas d'un émetteur de confiance |
| `aud` | Audience — à qui le jeton est destiné | Rejeter si votre service n'est pas l'audience visée |
| `exp` | Date d'expiration | Rejeter si l'heure actuelle est postérieure à `exp` |
| `nbf` | Date d'effet (Not-before) | Rejeter si l'heure actuelle est antérieure à `nbf` |
| `sub` | Sujet (Subject) — qui le jeton représente | Vérifier que l'utilisateur existe toujours / est actif |

Le fait de ne pas valider `iss` et `aud` permet des [attaques par relais inter-services](../vulnerabilities/broken-authentication/jwt-cross-service-relay-attack).

## Utiliser des durées de vie de jeton courtes avec rotation des jetons de rafraîchissement (Refresh Tokens)

Les jetons d'accès à courte durée de vie limitent les dommages causés par un jeton volé :

- **Jetons d'accès** : 5 à 15 minutes
- **Jetons de rafraîchissement** : de quelques heures à plusieurs jours, à usage unique (rotation à chaque utilisation)

Effectuez une rotation des jetons de rafraîchissement à chaque utilisation pour détecter le vol de jeton (si un jeton de rafraîchissement déjà utilisé est présenté, révoquez toute la session).

## Ne jamais utiliser `alg: none` en production

La spécification JWT autorise `alg: none` pour les jetons non sécurisés (par exemple, les messages échangés localement). Cela ne doit jamais être accepté par un point de terminaison d'API de production.

Sécurisez votre bibliothèque JWT pour rejeter explicitement `none` :

```go
// Exemple Go utilisant golang-jwt
token, err := jwt.Parse(tokenString, keyFunc, jwt.WithValidMethods([]string{"RS256", "ES256"}))
```

## Stocker les jetons de manière sécurisée sur le client

| Stockage | Risque XSS | Risque CSRF | Recommandation |
|----------|------------|-------------|----------------|
| `localStorage` | Élevé (lisible par JS) | Aucun | À éviter pour les jetons sensibles |
| `sessionStorage` | Élevé (lisible par JS) | Aucun | À éviter pour les jetons sensibles |
| Cookie `HttpOnly` | Aucun (non lisible par JS) | Moyen (à atténuer avec SameSite) | **Préféré** |
| Mémoire (variable JS) | Faible | Aucun | Acceptable pour les SPA |

Préférerez les cookies `HttpOnly; Secure; SameSite=Strict` pour les applications web. Voir [Mauvaise configuration des cookies HTTP](../vulnerabilities/security-misconfiguration/http-cookies) pour les vérifications associées.

## Références

- [OWASP JWT Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html)
- [RFC 7519 — JSON Web Token](https://datatracker.ietf.org/doc/html/rfc7519)
- [Auth0 — JWT Best Practices](https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-token-best-practices)
102 changes: 102 additions & 0 deletions docs/fr/best-practices/security-headers.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,102 @@
---
title: En-têtes HTTP de sécurité pour API
description: Découvrez l'importance des en-têtes HTTP de sécurité pour la sécurité des API et comment les tester à l'aide de VulnAPI.
---

import { Tabs, TabItem } from '@/components/docs'

Il est crucial de comprendre l'importance des en-têtes HTTP de sécurité, en particulier en ce qui concerne la sécurité des API. Ces en-têtes fournissent des fonctionnalités de sécurité et des protections importantes à la fois pour le serveur et pour le client.

## Comment tester ?

Si vous souhaitez tester uniquement que l'API envoie les bons en-têtes de sécurité, vous pouvez utiliser la commande suivante :

<Tabs>
<TabItem label="cURL">
```bash
vulnapi scan curl [url] --scans misconfiguration.http_headers
```
</TabItem>
<TabItem label="OpenAPI">
```bash
vulnapi scan openapi [OpenAPI_Path_Or_URL] --scans misconfiguration.http_headers
```
</TabItem>
<TabItem label="GraphQL">
```bash
vulnapi scan graphql --scans misconfiguration.http_headers [url]
```
</TabItem>
</Tabs>

## Politiques de sécurité du contenu de l'API (CSP)

Les en-têtes de politique de sécurité du contenu (CSP) sont essentiels pour atténuer divers risques de sécurité dans le contexte des API. CSP permet de prévenir un ensemble d'attaques, notamment :

- **Attaques par injection de données :** CSP peut restreindre les types de contenu pouvant être chargés, réduisant ainsi le risque que des attaquants injectent des données malveillantes dans les réponses de l'API.
- **Clickjacking (Détournement de clic) :** Bien qu'il s'agisse principalement d'une préoccupation pour les pages web, CSP peut également aider à atténuer le clickjacking en contrôlant l'encadrement du contenu.

### Exemple d'en-tête CSP sécurisé pour les API

```http
Content-Security-Policy: default-src 'none'; frame-ancestors 'none';
```

`frame-ancestors 'none';` garantit que la réponse de l'API ne peut pas être intégrée dans des iframes, empêchant ainsi les attaques de clickjacking car votre API ne devrait probablement pas être intégrée dans des iframes.

### Risques atténués par CSP

1. **Script intersite (XSS) :** En limitant les sources à partir desquelles les scripts peuvent être chargés, CSP aide à empêcher les attaquants d'injecter et d'exécuter des scripts malveillants.
2. **Injection de données :** En contrôlant les sources de contenu, CSP réduit le risque que des attaquants injectent des données malveillantes dans les réponses de l'API.
3. **Clickjacking (Détournement de clic) :** En spécifiant frame-ancestors, CSP peut empêcher l'intégration des réponses de l'API dans des iframes, atténuant ainsi les attaques de clickjacking.

L'implémentation d'en-têtes CSP dans vos réponses d'API est une mesure proactive pour améliorer la posture de sécurité de votre API, protégeant ainsi le serveur et les clients contre divers types d'attaques.

## Partage de ressources entre origines multiples de l'API (CORS)

Les en-têtes CORS contrôlent l'accès aux ressources à partir de différentes origines. Pour les API, une configuration CORS appropriée garantit que seuls les domaines de confiance peuvent accéder aux ressources de l'API, empêchant ainsi les accès non autorisés provenant de sites web potentiellement malveillants.

### Exemple d'en-tête CORS sécurisé pour les API

```http
Access-Control-Allow-Origin: https://trusted-domain.com
```

## Sécurité stricte du transport HTTP (HSTS)

Les en-têtes HSTS demandent au navigateur de toujours utiliser HTTPS lors de la communication avec le serveur, même si l'utilisateur saisit « http » dans la barre d'adresse. Cela permet d'éviter les attaques de l'homme du milieu et de garantir que toutes les données échangées entre le client et le serveur sont chiffrées.

### Exemple d'en-tête HSTS sécurisé pour les API

```http
Strict-Transport-Security: max-age=31536000; includeSubDomains
```

## X-Content-Type-Options

Cet en-tête empêche les navigateurs de procéder à l'analyse MIME (**MIME-sniffing**) d'une réponse pour s'écarter du type de contenu déclaré, ce qui peut aider à prévenir certains types d'attaques, telles que les attaques par confusion de type de contenu.

### Exemple d'en-tête X-Content-Type-Options sécurisé pour les API

```http
X-Content-Type-Options: nosniff
```

## X-Frame-Options

L'en-tête X-Frame-Options protège contre les attaques de clickjacking en empêchant la réponse de l'API d'être intégrée dans un frame ou une iframe sur un autre domaine.

### Exemple d'en-tête X-Frame-Options sécurisé pour les API

```http
X-Frame-Options: DENY
```

## X-Permitted-Cross-Domain-Policies (obsolète)

Cet en-tête spécifie le fichier de stratégie qui régit la manière dont les applications Flash et Adobe AIR peuvent interagir avec les ressources de l'API à travers différents domaines. Cependant, cet en-tête est obsolète et ne doit pas être utilisé dans les applications modernes.

## Références

- [OWASP REST Security Headers](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html#security-headers)
- [MDN CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP)
83 changes: 83 additions & 0 deletions docs/fr/first-scan.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
---
title: Votre première analyse
description: Lancez votre première analyse de sécurité d'API en moins d'une minute avec vulnapi scan curl.
sidebar:
order: 4
---

import { Steps, Aside, CardGrid, LinkCard } from '@/components/docs'

Le moyen le plus rapide d'essayer VulnAPI est d'utiliser `vulnapi scan curl`. Cela fonctionne comme curl — pointez-le vers n'importe quel point de terminaison HTTP et il commencera immédiatement à tester les vulnérabilités.

## Analyse de base

```bash
vulnapi scan curl https://api.example.com/endpoint
```

C'est tout. VulnAPI envoie une série de requêtes conçues au point de terminaison et affiche un rapport.

## Analyser un point de terminaison authentifié

La plupart des API réelles nécessitent une authentification. Transmettez un en-tête `Authorization` de la même manière que vous le feriez avec curl :

```bash
vulnapi scan curl https://api.example.com/endpoint \
-H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9..."
```

Vous pouvez répéter `-H` pour des en-têtes supplémentaires (clés d'API, en-têtes personnalisés, etc.) :

```bash
vulnapi scan curl https://api.example.com/endpoint \
-H "Authorization: Bearer <token>" \
-H "X-API-Key: <key>"
```

## Analyser un point de terminaison qui n'est pas en GET

Utilisez `-X` pour définir la méthode HTTP et `-d` pour envoyer un corps de requête :

```bash
vulnapi scan curl https://api.example.com/login \
-X POST \
-d '{"username":"alice","password":"secret"}' \
-H "Content-Type: application/json"
```

## Lire le rapport

Une fois l'analyse terminée, VulnAPI affiche un tableau comme celui-ci :

```
| OPERATION | RISK LEVEL | CVSS 4.0 SCORE | OWASP | VULNERABILITY |
|-----------------------------|------------|----------------|--------------------------|-----------------------------|
| GET /endpoint | High | 9.3 | API2:2023 Broken Auth | JWT Token is not verified |
| GET /endpoint | Medium | 5.1 | API8:2023 Security Misc | X-Frame-Options is missing |
| GET /endpoint | Info | 0.0 | API8:2023 Security Misc | HSTS Header is missing |
```

| Colonne | Signification |
|---------|---------------|
| **OPERATION** | La méthode HTTP et le chemin qui ont été testés |
| **RISK LEVEL** | Sévérité : Info / Low / Medium / High / Critical |
| **CVSS 4.0 SCORE** | Score numérique de 0.0 à 10.0 |
| **OWASP** | La catégorie OWASP API Security Top 10 |
| **VULNERABILITY** | Une brève description du résultat |

<Aside type="tip">
Une ligne de résumé située au-dessus du tableau indique le niveau de risque global le plus élevé. Commencez par là pour évaluer rapidement si le point de terminaison présente des problèmes critiques.
</Aside>

## Aucun résultat ?

Une analyse sans aucune ligne dans le tableau des vulnérabilités signifie que VulnAPI n'a rien trouvé avec un score CVSS supérieur au seuil par défaut de `1.0`. C'est un bon signe, mais pas une garantie — VulnAPI recherche un ensemble spécifique de [vulnérabilités connues](./vulnerabilities).

## Prochaines étapes

<CardGrid>
<LinkCard title="GitHub Action" href="./github-action" description="Automatiser les analyses sur chaque pull request." />
<LinkCard title="Formats de sortie" href="./reference/output-formats" description="Exporter les résultats au format JSON ou YAML." />
<LinkCard title="Référence de la CLI" href="./reference/cli" description="Toutes les options d'analyse et leurs valeurs par défaut." />
<LinkCard title="Vulnérabilités" href="./vulnerabilities" description="Toutes les vulnérabilités vérifiées par VulnAPI." />
</CardGrid>
29 changes: 29 additions & 0 deletions docs/fr/getting-started.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
---
title: Prise en main
description: Lancez votre première analyse de sécurité d'API en moins de cinq minutes.
sidebar:
order: 2
---

import { CardGrid, LinkCard, Steps } from '@/components/docs'

Lancez votre première analyse de sécurité d'API en moins de de cinq minutes.

<Steps>

1. **[Installer VulnAPI](./installation)** — Téléchargez un binaire précompilé pour Linux, macOS, Windows, ou exécutez-le via Docker.

2. **[Lancer votre première analyse](./first-scan)** — Utilisez `vulnapi scan curl` ou pointez VulnAPI vers votre spécification OpenAPI.

3. **Lire le rapport** — Comprenez les colonnes OPERATION / RISK LEVEL / CVSS / OWASP / VULNERABILITY et ce que signifie chaque résultat.

4. **[Automatiser dans la CI/CD](./github-action)** — Ajoutez l'action GitHub VulnAPI à votre workflow afin que chaque PR soit analysée automatiquement.

</Steps>

<CardGrid>
<LinkCard title="Installation" href="./installation" description="Télécharger et installer VulnAPI sur votre plateforme." />
<LinkCard title="Première analyse" href="./first-scan" description="Guide étape par étape pour votre première analyse." />
<LinkCard title="GitHub Action" href="./github-action" description="Automatiser les analyses dans votre pipeline CI/CD." />
<LinkCard title="Référence de la CLI" href="./reference/cli" description="Toutes les commandes, options et leurs valeurs par défaut." />
</CardGrid>
40 changes: 40 additions & 0 deletions docs/fr/github-action.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
---
title: GitHub Action
description: VulnAPI peut être intégré à votre pipeline CI/CD à l'aide de GitHub Actions. Cela vous permet d'automatiser les tests de sécurité et le scan de vulnérabilités de vos API dans le cadre de votre flux de développement.
---

VulnAPI peut être intégré à votre pipeline CI/CD à l'aide de [GitHub Actions](https://github.com/marketplace/actions/vulnapi-action). Intégrer VulnAPI à GitHub Actions vous permet de scanner vos API à la recherche de vulnérabilités et de risques de sécurité dans le cadre de votre pipeline CI/CD.

Cela vous permet d'automatiser les tests de sécurité et le scan de vulnérabilités de vos API dans le cadre de votre flux de développement, garantissant que vos API sont **sécurisées** et exemptes de vulnérabilités **avant leur déploiement en production**.

## Exemple de workflow

Voici un exemple de workflow GitHub Actions qui utilise VulnAPI pour scanner votre API à la recherche de vulnérabilités :

```yaml
name: VulnAPI

on: [push]

permissions:
contents: read

jobs:
build:
runs-on: ubuntu-latest

steps:
- name: Checkout
uses: actions/checkout@v6

- name: VulnAPI
uses: cerberauth/vulnapi-action@v2
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
curl: 'curl http://localhost:8080 -H "Authorization: Bearer eyJhbGci..."'
```

## Documentation

Pour plus d'informations sur l'utilisation de VulnAPI avec GitHub Actions, veuillez consulter la [VulnAPI GitHub Action](https://github.com/marketplace/actions/vulnapi-action) sur GitHub Marketplace.
Loading
Loading