Portfolio API Security Engineer : guide 2026

Un portfolio API security engineer en 2026 est un actif différenciant majeur sur un marché de l'emploi tendu où les recruteurs cherchent des preuves tangibles de compétence au-delà des CV et certifications. Pour un candidat junior à confirmé, un portfolio mature peut compenser le manque d'expérience formelle ; pour un senior, il accélère la mobilité (promotion interne, packages premium en externe). Six éléments dominants composent un portfolio API security crédible en 2026 : repo GitHub avec règles Spectral et checks Schemathesis custom + petits outils API security, réputation bug bounty avec focus API (HackerOne, YesWeHack, Intigriti, Bugcrowd), CVE publiées sur APIs open source moyennement populaires, contributions aux outils OWASP et écosystème open source (Schemathesis, Spectral, OWASP crAPI, OpenAPI spec), talks en conférences (de meetup local à SSTIC), publications techniques (blog perso, Medium, dev.to). Cet article détaille chaque élément avec stratégie de construction temporellement structurée, exemples concrets, plateformes à privilégier, métriques à suivre et patterns observés des profils top API security visibles en France 2026.

Pourquoi un portfolio fait la différence

Trois raisons structurelles font du portfolio un asset disproportionné pour un API security engineer.

Marché tendu, signal différenciant

Les profils API security purs restent rares en 2026 (estimation : moins de 2000 spécialistes dédiés en France pour des milliers de postes ouverts à 6 mois). Les recruteurs cherchent des signaux concrets pour différencier les candidats au-delà du CV textuel.

Compétences difficiles à mesurer en entretien

L'API security combine connaissances théoriques (OWASP API Top 10), maîtrise outils (Burp, Schemathesis, Spectral), expérience pratique (audits réels, exploitation BOLA/BFLA/BOPLA), capacité à formaliser (rapports, writeups). Un entretien d'1-2h peut difficilement valider l'ensemble. Le portfolio fournit des preuves vérifiables.

Pyramide de signal RH 2026

Le portfolio combine les 4 derniers signaux, les plus discriminants.

Pilier 1 — GitHub portfolio dédié

Un repo GitHub dédié sous votre nom (ou pseudo professionnel) qui consolide vos productions API security. Structure type 2026.

api-security-portfolio/
├── README.md                      # vitrine, présentation, liens externes
├── spectral-rules/                # règles custom OpenAPI linting
│   ├── owasp-api-top-10/
│   │   ├── api1-bola-detection.yaml
│   │   ├── api2-broken-auth.yaml
│   │   ├── api3-bopla-fields.yaml
│   │   ├── api4-rate-limit-headers.yaml
│   │   ├── api5-bfla-admin-paths.yaml
│   │   ├── api6-business-flow-limits.yaml
│   │   ├── api7-ssrf-callbacks.yaml
│   │   ├── api8-security-headers.yaml
│   │   ├── api9-versioning.yaml
│   │   └── api10-third-party-validation.yaml
│   └── README.md
├── schemathesis-extensions/       # checks et hooks custom
│   ├── checks/
│   │   ├── no_pii_in_response.py
│   │   ├── jwt_algorithm_strict.py
│   │   └── deprecated_endpoints_detection.py
│   └── README.md
├── tools/                         # petits outils API security
│   ├── api-bola-scanner/          # scanner BOLA paramétrable
│   │   ├── README.md
│   │   ├── bola_scanner.py
│   │   └── tests/
│   ├── jwt-fuzzer/                # outil fuzzing JWT (algorithm confusion, etc.)
│   ├── graphql-introspection-detector/
│   └── webhook-replay-tester/
├── writeups/                      # writeups détaillés
│   ├── crapi-walkthrough.md       # OWASP crAPI complet
│   ├── vampi-bola-chain.md
│   ├── graphql-batch-bypass.md
│   └── private-disclosure-2025-acme.md   # post-disclosure si autorisé
├── threat-modeling/               # case studies
│   └── case-study-fintech-api.md
├── talks/                         # slides + recordings
│   ├── owasp-france-2025-bola/
│   │   ├── slides.pdf
│   │   ├── recording-link.md
│   │   └── demo-code/
│   └── ...
└── resources/                     # collections curated
    ├── api-security-tools-2026.md
    ├── learning-path.md
    └── bookshelf.md

Ce qui rend ce repo discriminant

• Profondeur technique : pas juste des liens, mais du code réel exécutable que les recruteurs peuvent examiner.
• Documentation soignée : README clairs, instructions de démarrage, exemples.
• Activité régulière : commits étalés dans le temps (vs commit unique à la dernière minute), graphique de contributions vert.
• Issues et PRs ouvertes : démontre engagement communautaire.
• Stars et forks : signal d'adoption (même 50-100 stars sur un outil API security est valuable).

Règles Spectral custom : exemple concret

# spectral-rules/owasp-api-top-10/api3-bopla-fields.yaml
extends: spectral:oas
 
rules:
  no-sensitive-fields-in-response-schemas:
    description: |
      Response schemas must not contain fields with names matching
      sensitive patterns (password, hash, secret, token, ssn, internal_*).
      Detects OWASP API3:2023 BOPLA risks at OpenAPI design time.
    given: $.paths[*][*].responses[?(@property === '200' || @property === '201')].content.*.schema..properties
    severity: error
    then:
      function: pattern
      functionOptions:
        notMatch: "(?i)(password|hash|secret|token|ssn|internal_|_admin|_private|api_key|jwt_secret)"
 
  endpoints-must-have-security-defined:
    description: "API endpoints must explicitly declare security requirements"
    given: $.paths[*][?(@property !== 'parameters')]
    severity: error
    then:
      field: security
      function: defined
 
  no-write-operation-without-rate-limit-doc:
    description: "Write operations (POST/PUT/PATCH/DELETE) should document rate limit headers"
    given: $.paths[*][?(@.method === 'post' || @.method === 'put' || @.method === 'patch' || @.method === 'delete')].responses..headers
    severity: warn
    then:
      field: RateLimit-Limit
      function: defined

Petits outils API security : exemple

# tools/api-bola-scanner/bola_scanner.py
"""
BOLA Scanner : automated detection of Broken Object Level Authorization
in REST APIs. Tests if a user authenticated as user_a can access objects
owned by user_b.
"""
 
import argparse
import requests
from typing import List, Tuple
 
class BOLAScanner:
    def __init__(self, base_url: str, user_a_token: str, user_b_token: str):
        self.base_url = base_url
        self.user_a_token = user_a_token
        self.user_b_token = user_b_token
    
    def test_endpoint_bola(self, endpoint_template: str, object_ids: List[int]) -> List[Tuple[int, str]]:
        """
        Test BOLA on an endpoint template like '/api/orders/{id}'.
        Returns list of (object_id, status) for objects accessible by user_a
        that should belong to user_b.
        """
        findings = []
        
        for obj_id in object_ids:
            endpoint = endpoint_template.replace("{id}", str(obj_id))
            
            # User A tries to access
            response = requests.get(
                f"{self.base_url}{endpoint}",
                headers={"Authorization": f"Bearer {self.user_a_token}"},
                timeout=10,
            )
            
            if response.status_code == 200:
                # Verify object actually belongs to user_b
                response_b = requests.get(
                    f"{self.base_url}{endpoint}",
                    headers={"Authorization": f"Bearer {self.user_b_token}"},
                    timeout=10,
                )
                
                if response_b.status_code == 200 and response.json() == response_b.json():
                    findings.append((obj_id, "BOLA confirmed"))
        
        return findings
 
def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("--base-url", required=True)
    parser.add_argument("--token-a", required=True)
    parser.add_argument("--token-b", required=True)
    parser.add_argument("--endpoint", required=True, help="e.g. /api/orders/{id}")
    parser.add_argument("--id-range", required=True, help="e.g. 1-100")
    args = parser.parse_args()
    
    start, end = map(int, args.id_range.split("-"))
    scanner = BOLAScanner(args.base_url, args.token_a, args.token_b)
    findings = scanner.test_endpoint_bola(args.endpoint, list(range(start, end + 1)))
    
    if findings:
        print(f"BOLA findings: {len(findings)}")
        for obj_id, status in findings:
            print(f"  {args.endpoint.replace('{id}', str(obj_id))}: {status}")
    else:
        print("No BOLA detected")
 
if __name__ == "__main__":
    main()

Ce type d'outil simple mais fonctionnel, publié avec README clair et tests, démontre concrètement la capacité à automatiser la détection.

Pilier 2 — Réputation bug bounty avec focus API

Un compte HackerOne ou YesWeHack actif avec focus API est l'un des signaux les plus puissants en 2026.

Plateformes par ordre de priorité

Stratégie 2026 : ouvrir compte sur HackerOne + YesWeHack en priorité, ajouter Intigriti après 6 mois pour diversification.

Construire la rep API-focused

Phase 1 (mois 1-3) : VDP non rémunérés

Démarrer par les Vulnerability Disclosure Programs (VDP) gratuits pour construire la signal sans pression de payouts. Cibler programmes avec scope API étendu :

• HackerOne : filtrer par "API" dans search.
• YesWeHack : programmes avec api, webapi dans tags.

Objectif phase 1 : 3-5 submissions valides pour démarrer le profil.

Phase 2 (mois 3-9) : programmes payés moyens

Cibler programmes payés moyens (bounties 100-2000 $) sur stack tech moderne API :

• SaaS B2B avec API publique : Plausible, Sentry, Mautic, Strapi.
• Plateformes développeur : Vercel, Netlify, Render, Fly.io.
• DevOps tools : GitLab, Argo CD plugin APIs.

Objectif phase 2 : 10-20 submissions valides cumulées, premier triage validé sur API.

Phase 3 (mois 9-18) : private programs et premium

Une fois rep solide, recevoir invitations programmes privés (HackerOne Clear, YesWeHack invite-only) avec bounties significativement plus élevés.

Métriques à viser sur HackerOne

Tactiques de spécialisation API focus

Pour différencier votre rep d'un profil bug bounty généraliste :

1. Title clair : préciser "API Security" dans titre LinkedIn et bio HackerOne.
2. Tags consistents : taguer toutes vos submissions avec "API", "GraphQL", "OAuth", "REST".
3. Writeups thématiques : publier writeups (avec autorisation programme) thématisés API.
4. Spécialisation visible : devenir reconnu comme "le BOLA hunter" ou "GraphQL specialist" sur la plateforme.

Pilier 3 — CVE publiées

Une CVE publiée à votre nom est le trophée le plus discriminant en entretien API security. Stratégie d'accès accessible.

Cibler les bons projets

Plus le projet est petit/moyen, plus la barrière d'entrée à découvrir une CVE est basse. Cibles fertiles :

• Projets open source moyennement populaires : 5-30K stars GitHub, équipe de maintainers réduite, activité régulière mais pas trop scrutée. Exemples 2026 : SaaS open source moyens, plugins et extensions, bibliothèques de niche.
• APIs internes de SaaS B2B : si le SaaS expose une API publique documentée, audit cette API.
• APIs de tooling DevOps : Argo CD plugins, Jenkins plugins, GitLab CE features.
• Anciennes versions LTS : projets qui maintiennent des versions LTS plus anciennes ont parfois des CVE non patchées.

Éviter en démarrage : APIs Stripe, GitHub, AWS, Microsoft. Très scrutées, barrière d'entrée extrêmement haute, vous serez en concurrence avec des chercheurs full-time.

Processus de disclosure responsable

1. Découverte de la vulnérabilité (audit perso, lab, fuzz)
2. Validation : reproduire de manière fiable, documenter steps
3. Estimation impact + CVSS
4. Recherche du contact sécurité du projet
   - SECURITY.md du repo
   - security@domain ou similar
   - Page security du site projet
5. Disclosure responsable :
   - Email détaillé : description, steps to reproduce, impact, suggested fix
   - PoC en pièce jointe (idéalement vidéo + code)
   - Délai de patch : 90 jours standard (Project Zero policy)
6. Coordination patch :
   - Suivi régulier sans pression
   - Aide à la rédaction du fix si demandé
7. Demande CVE :
   - Soit le projet/CNA demande la CVE
   - Soit demande directe via MITRE CVE Request form
8. Publication coordonnée :
   - Patch + advisory simultanément
   - Article blog perso 1-2 semaines après
9. Promotion mesurée :
   - LinkedIn post avec mention CVE
   - Tweet thread technique
   - Mise à jour profil GitHub

Premier CVE typique

Profil rapide pour une première CVE en 6-12 mois : auditer 3-5 APIs open source moyennement populaires en applicant systématiquement OWASP API Top 10 2023, focus sur BOLA/BFLA (les plus communs), reporter responsiblement, attendre 60-120 jours pour publication.

Pilier 4 — Contributions open source

Contribuer aux outils API security mainstream amplifie votre crédibilité.

Projets cibles 2026

Workflow contribution efficace

1. Démarrer par "good first issue" : issues étiquetées par maintainers comme accessibles. Filter sur GitHub.
2. Documenter avant de coder : commenter l'issue avec votre approche, attendre validation maintainer.
3. PR petite et ciblée : éviter PR géantes refactorisantes. Une PR = un fix ou une feature précise.
4. Tests inclus : toute PR avec tests passe plus vite la review.
5. Patience : maintainers répondent en jours/semaines, pas en heures. Ne pas spammer.
6. Constance : 1-2 PR mergées par trimestre suffit pour démontrer engagement long terme.

Premier ROI : ouvrir issue qualifiée

Avant la première PR, ouvrir une issue bien documentée (bug rapporté avec reproduction, ou feature request avec use case détaillé). Crée une première interaction positive avec les maintainers.

Pilier 5 — Talks en conférences

Présenter publiquement amplifie crédibilité et ouvre opportunités carrière.

Pyramide des conférences France 2026

Niveau 1 — Meetups locaux (entrée)

Niveau 2 — Conférences spécialisées

Niveau 3 — Référence

Stratégie de progression

Mois 0-12 : Niveau 1 (1-2 talks meetups)
Mois 12-24 : Niveau 2 (1-2 conférences spécialisées)
Mois 24+ : Niveau 3 (SSTIC, LeHack si plusieurs talks niveau 2 préalables)

Topics percutants 2026 pour API security

• "BOLA detection automation : retour d'expérience à grande échelle"
• "GraphQL fuzzing avec Schemathesis : 5 patterns d'attaque"
• "FAPI 2.0 audit en pratique : checklist banking"
• "API security en multi-tenant SaaS : 3 patterns de l'industrie"
• "OAuth 2.1 deprecations : ce qui change, ce qui reste"
• "Webhook security : leçons de 50 audits"
• "BOLA en GraphQL : différences avec REST"
• "API discovery via eBPF : automation pratique"

Préparation talk efficace

• Slides claires, pas de mur de texte.
• Démos live (avec backup vidéo en cas de problème réseau) : très impactant.
• Take-aways concrets : 3-5 points actionnables que l'audience peut appliquer dès lundi.
• Code disponible publiquement : repo GitHub avec tout le code de la démo.
• Recording + slides publiés post-conférence sur le portfolio GitHub.

Pilier 6 — Publications techniques

Articles longs forme amplifient l'autorité technique.

Plateformes 2026

Format efficace

• Longueur : 2000-4000 mots pour articles techniques approfondis.
• Code source partagé : repo GitHub référencé dans l'article.
• Visuels : diagrammes (Excalidraw, Mermaid), captures d'écran, screencasts.
• Sourcing : citer OWASP, RFCs, papers, blog originaux pour crédibilité.
• Updates : revisiter articles populaires chaque trimestre pour refresh.

Series qui fonctionnent

• "OWASP API Top 10 2023 : exploitations pratiques" (10 articles, un par classe).
• "Audit GraphQL en pratique" (multi-articles patterns).
• "Construire un programme API security from scratch" (série pour CISOs).

Construire le portfolio en 18 mois : roadmap

Plan structuré pour démarrer de zéro.

Mois 1-3 — Fondations

• Création comptes HackerOne + YesWeHack avec bio focus API security.
• Création repo GitHub portfolio (squelette avec README).
• Lecture intégrale OWASP API Security Top 10 2023.
• Pratique sur OWASP crAPI + vampi (writeups internes).
• Premier outil simple publié sur GitHub (par exemple : BOLA scanner basique).

Mois 3-6 — Premières productions visibles

• Premier writeup public sur le blog ou Medium.
• 5+ submissions bug bounty VDP (rep initiale).
• Premières règles Spectral custom publiées.
• Premier talk meetup OWASP France local.

Mois 6-12 — Montée en visibilité

• 15+ submissions bug bounty cumulées avec rep > 100.
• 3-5 contributions open source mergées (Schemathesis, Spectral, OWASP crAPI).
• 2-3 articles techniques publiés.
• 1-2 talks meetups niveau 1.
• Première CVE en cours de disclosure.

Mois 12-18 — Crédibilité senior

• Première CVE publiée.
• 30+ submissions bug bounty avec rep > 500.
• Talk niveau 2 (Hexacon, Pass the Salt, ou similar).
• 10+ articles publiés.
• Mention sur LinkedIn post viralizant (1000+ likes type).
• Approche directe de recruteurs senior + offres entrantes.

Métriques de succès portfolio

KPIs à suivre pour piloter le portfolio.

Erreurs portfolio à éviter

Cinq écueils observés.

Repos GitHub abandonnés. Démarrer 10 outils, n'en finir aucun. Préférable d'avoir 2-3 outils bien finis avec docs et tests qu'10 squelettes vides.

Profil HackerOne avec mauvais signal. Submitter en volume sans qualité = signal qui chute = invitation aux programmes privés bloqués. Toujours qualité > volume.

Talks sans recording publié. Talk donné en présentiel sans vidéo perd 80 % de sa valeur portfolio (pas vérifiable). Toujours s'assurer du recording, le mettre sur portfolio.

LinkedIn générique. Profil sans mention API security, sans posts, sans articles = invisible aux recruteurs spécialisés. Optimisation LinkedIn ciblée API security obligatoire.

Pas de stratégie de promotion. Publier sans amplifier (LinkedIn post, Twitter, Bluesky) = personne ne lit. Réserver 20 % du temps portfolio à la promotion.

Points clés à retenir

• Un portfolio API security engineer en 2026 est un asset différenciant majeur sur un marché tendu : compense l'absence d'expérience formelle, accélère la mobilité interne et externe.
• Six piliers : GitHub portfolio (règles Spectral/Schemathesis, outils, writeups), bug bounty rep avec focus API (HackerOne, YesWeHack), CVE publiées sur APIs open source, contributions OWASP/Schemathesis/Spectral, talks meetups → conférences spécialisées → SSTIC/LeHack, publications techniques (blog perso, Medium, dev.to).
• Roadmap 18 mois structurée : fondations (mois 1-3) → premières productions visibles (3-6) → montée en visibilité (6-12) → crédibilité senior avec première CVE et talk niveau 2 (12-18).
• Métriques 12 mois cibles : 100+ rep HackerOne avec signal > 3, 5+ contributions OSS mergées, 50+ GitHub stars, 1-2 talks meetups, 5+ articles publiés.
• Pyramide conférences France : meetups OWASP/Paris Web/AppSec Day (entrée), Hexacon/Pass the Salt/NorthSec/GreHack (intermédiaire), SSTIC/LeHack (référence après plusieurs niveaux 2). Démarrer petit, monter progressivement.

Pour aller plus loin

• Roadmap API Security 2026 - parcours complet d'apprentissage que le portfolio illustre.
• Passer de développeur à expert API security - trajectoire compressée 6-12 mois pour profils dev.
• Méthodologie de pentest API - méthodologie offensive pour alimenter les writeups portfolio.
• Comment tester une API - patterns testing utilisés dans les outils du portfolio.