Siirry sisältöön

API-auditoinnin tarkistuslista

Kattava tarkistuslista API-valmiuden tarkistamiseksi ennen julkaisemista, joka kattaa suunnittelun, dokumentoinnin, tietoturvan ja käytäntöjen noudattamisen.

  • Parempi ymmärrys API-auditoinnin tarkistuslistan periaatteista
  1. Varmista API-auditoinnin tarkistuslistan avulla, että API-suunnittelu täyttää toiminnalliset ja muut kuin toiminnalliset vaatimukset, mukaan lukien tietoturva, suorituskyky ja vaatimustenmukaisuus.
  2. Suorita tarkastuksia varmistaaksesi, että sovellusrajapinnat täyttävät organisatoriset, tekniset ja oikeudelliset standardit ennen julkaisemista.
  3. Varmista, että turvamallit, yhdyskäytävän kokoonpano ja oikeudelliset ehdot ovat selkeitä ja kuluttajien saatavilla.

REST API -tarkistuslista

✅ Konsepti on valmis kun…

KriteeritOWASP API Top 10OpenAPI 3.1.x
API perustuu selkeisiin liiketoiminnallisiin tarpeisiinAPI9:2019
API kätkee raa’an taustatiedon; suunniteltu yhteiskäyttöön.API6:2023
Päätepisteillä on liiketoiminta-arvo ja ominaisuuksien kuvaukset.API9:2023✅ (kuvauksen kautta)
APIn suunnittelu on yhdenmukainen muiden APIen kanssaAPI8:2023, API9:2023
Tietojen/attribuuttien nimeämisessä käytetään kuvailevaa englantia.-
Pakolliset kentät on määriteltyAPI6:2019✅ (pakollisen kautta)
Päivämäärät käyttävät ISO-muotoa aikavyöhykkeineenAPI8:2019✅ (via format: date-time)
Yleiset tiedot käyttävät vakioarvoja (esim. ISO).API6:2023, API8:2019➖ (via enum, format, pattern)
Kenttien nimissä vältetään lyhenteitä, käytetään kokonaisia sanoja.API9:2023
Uusien resurssien luominen palauttaa tunnuksetAPI2:2023✅ (vastausskeeman/esimerkin kautta)

🧪 API-suunnittelun prototyyppi on valmis kun…

KriteeritOWASP API Top 10OpenAPI 3.1.x
Kaikki konseptin tarkistuslistan kohdat on tarkastettu-
Loppupisteen polut sisältävät enintään kaksi resurssia/aliresurssia.-
Päätepisteet ja attribuutit sisältävät esimerkkejä-✅ (esimerkin kautta, esimerkit)
POSTia käytetään luomiseen/päivittämiseen (ei PUTia, ellei se ole täysi).-
DELETEa käytetään resurssien poistamiseen-
Versionointistrategia päätetään; yhdyskäytävä tukeeAPI9:2023
GET:llä ei ole pyyntörunkoa; palauttaa 200 OK sisällön kanssa.-➖ (konventio; ei pakollinen)
GET palauttaa 204, jos vastauksen runko on tyhjä-✅ (voi määritellä 204-vastauksen)
POST palauttaa 200 OK päivityksen yhteydessä-✅ (voi määritellä tilakoodit)
POST palauttaa 201 Created with ID on create-
DELETE palauttaa 204 OK onnistumisen yhteydessä-
400 virheet antavat tarkat virhetiedotAPI6:2023✅ (kuvattu vastausskeemassa)
401 Unauthorized väärien tunnusten vuoksi.API2:2023✅ (vakiovastausdokumentaatio)
403 Kielletty, kun kyseessä on luvaton operaatio.API5:2023

🚀 API on ylläpidettävissä tuotannossa, kun…

KriteeritOWASP API Top 10OpenAPI 3.1.x
Kaikki prototyyppi/suunnittelukohteet auditoitu-
Julkaistu API-hallinnan kauttaAPI10:2019, API8:2023
Näkyy kehittäjäportaalissaAPI9:2023
Pääsee vain API-portin kauttaAPI9:2023, API8:2023
Nopeusrajoitukset on otettu käyttöönAPI4:2023
Asiakirjat luodaan automaattisesti spekseistä/skeemasta.API9:2023
Eritelmä päivittyy automaattisesti yhdyskäytävään/laitteistoportaaliin.API9:2023✅ (epäsuorasti työkalujen kautta)
Spec validoidaan jokaisen muutoksen yhteydessä-✅ (paras käytäntö)
Eritelmä sisältää pyyntö- ja vastausskeeman.-
Skeema ja esimerkit läpäisevät validoinnin-
Käyttää HTTPS:ää tai salattuja protokollia.API10:2023
Julkaistu virallisessa org-verkkotunnuksessaAPI8:2023
Autentikoinnilla suojatut päätepisteetAPI2:2023, API4:2023➖ (voi määritellä securitySchemes)
Token-pohjainen todennus-✅ (securitySchemesin kautta)
Suojattu CSRF:ltäAPI8:2023
Kehys validoi syötteet automaattisestiAPI8:2023✅ (epäsuorasti skeeman kautta)
Ulostulot automaattinen poisto kehyksen toimestaAPI8:2023
Tietojen salaus siirrossa/varastoinnissa olevien tietojen osaltaAPI8:2023
Viestin eheys toteutettuAPI6:2023, API7:2023
UUID-tunnukset/pseudotunnisteet tietokantatunnusten sijasta.API7:2023➖ (suositellaan esimerkissä)
URL-osoitteissa ei ole arkaluonteisia tietojaAPI7:2023
HTTP-menetelmät vain tarkoitetuille resursseilleAPI5:2023✅ (määritelty poluissa)

ASync APIn tarkistuslista
✅ Konsepti on valmis kun…

KriteeriAsyncAPI 2.x
API perustuu selkeisiin liiketoiminnallisiin tarpeisiin
API kätkee raa’at taustatiedot; suunniteltu yhteiskäyttöön.
APIlla on kuvaus, joka selittää sen liiketoiminnallisen arvon ja ominaisuudet.
API on rakenteeltaan yhdenmukainen muiden APIjemme kanssa.
APIn ja tietojen nimeämisessä käytetään hyvää englantia (tai muuta standardikieltä).
Pakolliset kentät on määritelty
Päivämäärät ovat ISO-standardin mukaisessa päivämäärämuodossa, mukaan lukien aikavyöhyke.
Yleisissä tiedoissa käytetään vakioarvoja (esim. ISO).
Kentät on kuvattu sanatarkasti, lyhenteitä välttäen.
Uusia viestejä julkaistaessa asiaankuuluvat aiheet tai kanavat yksilöidään selkeästi.

🧪 API-suunnittelun prototyyppi on valmis, kun…

KriteeriAsyncAPI 2.x
Kaikki konseptin tarkistuslistan kohdat on tarkastettu
Viestisuunnittelu sisältää selkeän rakenteen (tapahtumat, komennot, kyselyt).
Kaikkiin viesteihin ja attribuutteihin sisältyy esimerkkejä
Viestit noudattavat johdonmukaista rakennetta eri aiheissa/kanavissa.
Viestien versiointistrategia on päätetty
Vastaanotettujen viestien kuittaukset on määritelty (tarvittaessa).
Virheet tai ongelmat, joihin liittyvät viestit sisältävät erityisiä virhetietoja.
Tunnistus- ja valtuutusstrategiat on määritetty

🚀 API on ylläpidettävissä tuotannossa, kun…

KriteeriAsyncAPI 2.x
Kaikki prototyypin ja API-suunnittelun tarkistuslistojen kohteet tarkastetaan.
APIta hallinnoidaan asianmukaisen AsyncAPI-hallintatyökalun avulla.
API näkyy kehittäjäportaalissa
Viestien lähettämisessä noudatetaan nopeusrajoituksia (tarvittaessa).
API-dokumentaatio luodaan automaattisesti AsyncAPI-spekseistä.
Eritelmä päivittyy automaattisesti API-työkaluihin ja portaaliin.
Aiheiden/kanavien määrittely validoidaan jokaisen muutoksen yhteydessä.
Määrittely sisältää viestien skeeman
Viestien skeema ja esimerkit läpäisevät skeeman validoinnin.
Viestien siirto varmistaa turvallisuuden (esim. MQTT/AMQP TLS:n kautta).
APIta käytetään organisaation virallisen verkkotunnuksen alla.
Kaikki aiheet/kanavat on suojattu todennuksella.
APIssa on tunnisteisiin perustuva todennus
Tietojen salaus siirrossa ja tallennuksessa toteutetaan tarpeen mukaan.
Viestien eheys on toteutettu tarpeen mukaan
UUID-tunnuksia tai pseudotunnisteita käytetään tietokantatunnusten sijasta.
Arkaluonteisia tietoja ei paljasteta aiheissa tai kanavissa.
Whitelistingin avulla määritetään, mitkä asiakkaat voivat julkaista/tilata.