Aller au contenu principal
Journal

Journal des modifications de l’API

Chaque changement susceptible d’affecter une intégration, du plus récent au plus ancien.

Voir la documentation API
  1. v3.1.1Nouveauté

    Certificats : ce que le site présente, et son historique CT

    La section certificats ne dépend plus de crt.sh seul. certificateFacts donne deux parties, chacune avec sa source : le certificat que le site présente maintenant, lu par notre propre poignée de main TLS sur le port 443, et l'historique Certificate Transparency de crt.sh. Une source qui n'a pas répondu vaut unknown, jamais none.

    • certificateFacts sur /check (à tous les niveaux d'enrichissement), /check/certificates et le flux du rapport ; dataTrust.certificates en donne l'état et la source
    • certificates (lignes crt.sh) compte désormais au plus dix lignes, certificats en cours d'abord, sans le doublon précertificat/certificat final ; certificateFacts.ctHistory donne currentCount et totalSeen
    • /check/certificates et le flux du rapport ouvrent une connexion TLS vers la cible sur le port 443 (aucune requête HTTP, jamais vers un domaine que nous jugeons malveillant) ; /check, /check/domain-risk et l'analyse en masse lisent les caches seulement
    • Une adresse IP n'a pas de section certificats : certificateFacts vaut not_applicable et rien n'est contacté
  2. v3.1.0Nouveauté

    Analyse d’e-mails : POST /mail/scan

    Analysez un e-mail entrant pour y détecter phishing et malwares en un seul appel : un verdict, une action recommandée et les raisons. Il consomme le compteur de scans, un scan par message, jamais le quota de requêtes.

    • Envoyez le message brut (eml ou emlBase64, jusqu’à 10 Mio) ou les champs que vous avez déjà extraits (message)
    • La réponse contient un verdict (malicious, suspicious, clean ou inconclusive), une action recommandée (quarantine, review, warn ou deliver), un score de risque et les raisons
    • Il lit l’expéditeur, le Reply-To, les hôtes des liens, les empreintes et la structure des pièces jointes, les imitations de marques connues, et la politique DMARC et SPF que l’expéditeur publie ; il n’ouvre jamais une pièce jointe, ne suit jamais un lien et ne conserve pas le message
  3. v3.0.1Nouveauté

    Authentification HTTP Basic pour les identifiants API

    Authorization: Basic est accepté partout où X-API-KEY l’est. La forme standard est utilisateur = apiKey et mot de passe = apiSecret. La forme TAXII/Sentinel (n’importe quel utilisateur, mot de passe = identifiant Base64) reste valable.

    • curl -u apiKey:apiSecret fonctionne sur /check, les blocklists, TAXII et le reste de l’API
    • Les équipements qui limitent un champ de clé API à 64 caractères peuvent utiliser Basic Auth
    • L’ancienne forme utilisateur api + mot de passe Base64 reste valide
  4. v3.0.0Changement cassant

    Hôte et chemins canoniques de l’API (Rust)

    L’API REST publique se trouve sur https://api.ismalicious.com, avec des chemins racine (/check, /bulk/check, …). La documentation a été mise à jour en conséquence.

    • Authentification : X-API-KEY = Base64(apiKey:apiSecret) — et non Authorization: Bearer pour les clés API
    • Recherche unitaire : GET /check?query= — les exemples /v1/lookup/... sont supprimés
    • Bulk : POST /bulk/check en JSON { entities[], enrichment? }
    • Vérification progressive : SSE GET /check/stream?query=
    • Webhooks utilisateur : CRUD sur /user/webhooks pour les offres payantes ; OpenAPI sur /openapi.json

Commencez avec une clé API gratuite

250 requêtes par mois. Aucune carte bancaire requise.

Créer un compte