Przejdź do treści
Biblioteka skilli
Bezpieczeństwo · Budowanie i kod

secure-api-design

/secure-api-design

Projektuje i wdraża bezpieczne API: wzorce uwierzytelniania, modele autoryzacji, walidację wejścia, obsługę sekretów i bezpieczne ustawienia domyślne.

Licencja
MIT
Ostatnia zmiana repozytorium
20.07.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
1
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 20.07.2026, bez odwołań do wycofanych modeli i API.

Licencja

MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.

Co robi i kiedy

Projektuje i wdraża bezpieczne API: wzorce uwierzytelniania, modele autoryzacji, walidację wejścia, obsługę sekretów i bezpieczne ustawienia domyślne.

Wyzwalacze z opisu

secure APIauth designJWTOAuthAPI best practices
Oryginalny opis (EN)

Design and implement secure APIs—authentication patterns, authorization models, input validation, secrets handling, and safe defaults. Use when designing new endpoints, auth flows, or reviewing API contracts. Triggers: "secure API", "auth design", "JWT", "OAuth", "API best practices".

Jak działa

  1. Defaults
  2. Authentication patterns
  3. Authorization
  4. Contract-first (public APIs)
  5. Input and output
  6. Secrets
  7. Implementation checklist
  8. Related
Sekcje z nagłówków SKILL.md, w oryginale · 56 linii, 282 słów
Podgląd SKILL.md
---
name: secure-api-design
description: >
  Design and implement secure APIs—authentication patterns, authorization models,
  input validation, secrets handling, and safe defaults. Use when designing new
  endpoints, auth flows, or reviewing API contracts.
  Triggers: "secure API", "auth design", "JWT", "OAuth", "API best practices".
---

# Secure API design

## Defaults

- Deny by default; explicit allow per route and role.
- Validate at boundary; typed schemas (OpenAPI/JSON Schema/protobuf).
- Least privilege for service accounts and API keys.

## Authentication patterns

| Pattern | Use when | Notes |
|---------|----------|-------|
| Session cookie | Browser-first apps | CSRF protection, secure cookies |
| Bearer JWT | SPA/mobile, stateless | Short TTL, rotation, no sensitive claims in payload |
| API key | Machine-to-machine | Scoped keys, audit log, rate limits |
| OAuth2/OIDC | Third-party identity | Standard libraries; validate issuer/audience |

## Authorization

- Resource-level checks close to data access (not only route middleware).
- Avoid exposing sequential IDs without ownership check.
- Document policy matrix: role x action x resource.

## Contract-first (public APIs)

- Define OpenAPI/JSON Schema **before** implementation when the API is shared.
- Version breaking changes; additive fields preferred.
- **Hyrum's Law:** undocumented behavior becomes dependency—document or forbid.
- Stable error shape: machine-readable `code`, human `message`, optional `details[]`.
- Pagination: cursor preferred for large sets; cap `limit`; document sort order.

## Input and output

- Reject unknown fields on write endpoints when schema allows.
- Normalize encoding; limit string/array sizes.
- Redact secrets in logs; structured logging without raw tokens.

## Secrets

- Never commit secrets; use env/secret manager.
- Separate dev/stage/prod credentials.
- Rotate on leak suspicion.

## Implementation checklist

- [ ] Schema validation on all inputs
- [ ] Authn required except explicit public routes
- [ ] Authz enforced per resource
- [ ] Rate limits on login and expensive operations
- [ ] Security headers and TLS termination documented

## Related

Use `api-security-testing` before release for verification.

Wersje

W bazie nie ma innych skilli o nazwie secure-api-design.

Identyczna treść występuje jeszcze w 1 innych folderach na GitHubie. Tu pokazujemy jedną, najlepiej ocenioną kopię.

Migawka bazy z 28.10.2026 · wersja paczki de5857233109 (skrót SHA-256 całej paczki)

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 100building-api-authentication
    Buduje bezpieczne systemy uwierzytelniania API z OAuth2, JWT, kluczami API i zarządzaniem sesjami.
  • 100building-api-authentication
    Buduje bezpieczne systemy uwierzytelniania API z OAuth2, JWT, kluczami API i zarządzaniem sesjami.
  • 95api-security-auth-pattern
    Projektuje i dokumentuje wzorce uwierzytelniania, autoryzacji i zabezpieczeń API: OAuth 2.0, JWT, klucze API, RBAC, ABAC, CORS, walidacja wejścia i OWASP API Security.
  • 100security-patterns
    Wdraża wzorce uwierzytelniania, autoryzacji, szyfrowania i zarządzania sekretami: JWT, OAuth, hashowanie haseł, klucze API i RBAC.
  • 100auth-system
    Wdraża bezpieczne systemy uwierzytelniania i autoryzacji z JWT, OAuth2, sesjami i RBAC, w tym logowanie, haszowanie haseł, middleware API oraz 2FA/MFA.
  • 100security
    Wymusza obronę w głąb, walidację danych wejściowych i bezpieczne domyślne ustawienia przy nietrywialnych zmianach w kodzie.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.