Přeskočit obsah

Audit API — metodika

Backend (backend/) je request/response API nad daty. Manuální testovací scénáře kontrolují, co ukáže UI. Nenajdou ale, co API udělá, když ho nezavolá UI, ale někdo jiný: nepřihlášený člověk, klient s cizím ID nebo terapeut, který si změní filtr. Tenhle audit prochází API přímo a každý nález podloží Pest testem.

Členění

Jedna stránka = jeden zdroj dat, ne jedna routa. Stránka pokrývá všechny cesty k datům zdroje: interní /api/..., veřejné /api/public/... i akce funkcí (clientBooking, clientAuth…). Díry obvykle vznikají na rozdílu mezi interní a veřejnou cestou ke stejným datům, a ten je vidět jen vedle sebe.

Seznam zdrojů a jejich stav: Přehled.

Checklist pro každý zdroj

U každé routy a akce zdroje projdi:

  1. Autentizace: kdo se k endpointu dostane bez přihlášení, s klientskou session, se staff session?
  2. Role a oprávnění: odpovídá middleware tomu, kdo má data vidět? Liší se veřejná a interní cesta?
  3. Omezení na firmu: filtruje se podle company_id přihlášeného?
  4. Cizí ID: dá se v requestu podstrčit id, client_id, booking_id, therapist_id, a dostat tak cizí záznam?
  5. Co odpověď vrací navíc: SELECT * do veřejné odpovědi, interní poznámky, tajné klíče, osobní údaje.
  6. Zápis a vedlejší efekty: která pole jde zapsat, obchází zápis obchodní pravidla (storno, platba), posílá e-mail/SMS?
  7. Kdo to volá z Reactu: najdi volání v react_dev/src. base44Client.js volí veřejnou nebo interní routu podle URL stránky a při 401/403 zkouší veřejnou (viz PRU-03), takže bez tohohle kroku nevíš, kterou routu frontend skutečně trefí.

Formát nálezu

### REZ-01 — Krátký popis (závažnost)

**Stav:** otevřený | opravený | přijaté riziko

**Test:** `tests/Feature/Audit/RezervaceAuditTest.php` → `REZ-01: …`

**Ověřený fakt** — soubor:řádek. Co kód dělá.

**Dopad** — co to umožní a komu.

**Odvozeno** — co z toho plyne, ale v kódu to přímo není (pokud je co).

Závažnost: kritická (únik dat nebo zásah do cizích dat bez přihlášení), vysoká (totéž s přihlášením, ale mimo roli), střední (obchází obchodní pravidlo), nízká (funkční chyba, kosmetika).

Tvrzení se dělí podle pravidel dokumentace: ověřený fakt (vyčteno z kódu nebo potvrzeno testem), odvozeno (plausibilní závěr), nezjištěno (otázka).

Testy

Každý nález má Pest test v backend/tests/Feature/Audit/, v názvu testu je ID nálezu. Test popisuje správné chování, takže dokud nález není opravený, test padá. Otevřené nálezy jsou ve skupině audit-open.

Spouští se stejně jako ostatní backend testy (kde a v jakém prostředí, viz Spouštění testů), jen s volbou skupiny:

cd backend
TEST_DB_DSN='mysql:host=<db-host>;dbname=<databáze_s_test_v_názvu>' \
TEST_DB_USER='<uživatel>' \
TEST_DB_PASSWORD='<heslo>' \
php -d xdebug.mode=off vendor/bin/pest --group=audit-open
  • --group=audit-open zobrazí stav otevřených nálezů (dnes červené),
  • --exclude-group=audit-open pustí zbytek sady, ten má zůstat zelený,
  • DB musí mít v názvu test, bootstrap v ní na začátku běhu znovu zakládá tabulky a před každým testem maže data.

Po opravě nálezu se u testu odstraní ->group('audit-open') a v dokumentaci se stav změní na opravený. Od té chvíle test hlídá, aby se chyba nevrátila.

Pravidla pro opravu

  • Test je minimum, ne celá specifikace. Nález je opravený, až je odstraněná příčina popsaná v dokumentaci, ne jen až projde test. Příklad: u REZ-03 nestačí vyřadit z odpovědi notes, když veřejný list dál vrací SELECT * se všemi ostatními sloupci.
  • Test se neupravuje, aby prošel. Když autor kódu s nálezem nesouhlasí, test zůstane a nález se v dokumentaci označí jako přijaté riziko se zdůvodněním. O přijetí rizika rozhoduje odpovědná osoba projektu, ne autor opravy.

Kdy je zdroj hotový

Zdroj je prověřený, když:

  • prošel celým checklistem,
  • v přehledu je zapsaný commit, proti kterému se kontrolovalo,
  • každý nález má test a žádný nezůstal ve stavu otevřený (opravený nebo vědomě přijaté riziko).

Když se od zapsaného commitu změní controller nebo routy zdroje, stav se vrací na k přezkoumání:

git diff --stat <commit>..HEAD -- backend/src/routes.php backend/src/Controllers/<Controller>.php

Jak pustit kontrolu s AI

Stačí jedna věta, stejně pro Claude i Codex:

Proveď audit zdroje Klienti podle docs/api-audit/index.md.

Název zdroje je z tabulky v Přehledu. AI si zbytek přečte odsud.

Postup pro AI

  1. V Přehledu najdi řádek zdroje. Sloupec Entity a funkce určuje rozsah.
  2. V backend/src/routes.php a controllerech najdi všechny routy a akce, které s těmito entitami pracují, interní /api i veřejné /api/public.
  3. Projdi checklist včetně volání z react_dev/src.
  4. Každý nález ověř Pest testem v backend/tests/Feature/Audit/<Zdroj>AuditTest.php, skupina audit-open, ID nálezu v názvu testu. Test musí padat přesně na nálezu.
  5. Zapiš stránku docs/api-audit/<zdroj>.md podle vzoru Rezervace a přidej ji do navigace v zensical.toml.
  6. Aktualizuj řádek v Přehledu: stav, commit (git rev-parse --short HEAD), počet otevřených nálezů.
  7. Měň jen testy a dokumentaci, produkční kód ne.

Když na kontrole spolupracují dva modely, jeden hledá a druhý nálezy zpochybňuje. Do dokumentace jde jen výsledek, ne průběh debaty.