From bitwarden-security-engineer
This skill should be used when the user asks to "review the security architecture", "check authentication patterns", "evaluate trust boundaries", "review encryption implementation", "assess authorization design", or needs to evaluate system designs for authentication, authorization, data protection, or cryptographic correctness.
npx claudepluginhub bitwarden/ai-plugins --plugin bitwarden-security-engineerThis skill uses the workspace's default tool permissions.
Review these aspects of token-based authentication:
Provides OWASP security design principles, STRIDE threat modeling, and architectural mitigations. Use when designing systems or reviewing architecture for security.
Guides security architecture for auth/authorization including JWT rotation, OAuth2/OIDC, encryption at-rest/in-transit, OWASP top 10, zero-trust patterns, mTLS, RLS multi-tenancy. Use when designing or reviewing secure services.
Performs security architecture review with Zero Trust assessment, identifying authentication/authorization gaps, data protection issues, and providing prioritized remediation guidance. Useful for auditing codebase security.
Share bugs, ideas, or general feedback.
Review these aspects of token-based authentication:
| Aspect | Secure Pattern | Anti-Pattern |
|---|---|---|
| Issuance | Short-lived tokens with refresh mechanism | Long-lived tokens that never expire |
| Validation | Validate signature, issuer, audience, and expiry on every request | Validate only the signature, or skip validation for "internal" calls |
| Storage (server) | Stateless JWT or server-side session store | Token stored in querystring or URL |
| Storage (client) | HttpOnly Secure cookies or secure platform storage | localStorage, sessionStorage, or cookies without HttpOnly/Secure flags |
| Refresh | Refresh token rotation (old refresh token invalidated on use) | Reusable refresh tokens with no rotation |
| Revocation | Token blocklist or short expiry + refresh rotation | No revocation mechanism for compromised tokens |
// CORRECT — explicit role check at the API layer
[Authorize(Roles = "Admin")]
public async Task<IActionResult> DeleteUser(Guid userId)
// WRONG — checking role in business logic with string comparison
if (currentUser.Role == "admin") // Fragile, case-sensitive, easy to bypass
// WRONG — trusts the userId from the route, no ownership check
public async Task<Cipher> GetCipher(Guid cipherId) {
return await _cipherRepository.GetByIdAsync(cipherId);
}
// CORRECT — verify the requesting user owns the resource
public async Task<Cipher> GetCipher(Guid cipherId) {
var cipher = await _cipherRepository.GetByIdAsync(cipherId);
if (cipher.UserId != _currentContext.UserId)
throw new NotFoundException();
return cipher;
}
When reviewing architecture, identify data by classification:
| Classification | Examples | Required Protection |
|---|---|---|
| Critical | Encryption keys, master passwords, vault data | End-to-end encryption, HSM key storage |
| Confidential | PII, email addresses, billing info | Encryption at rest + in transit, access logging |
| Internal | Organizational settings, feature flags | Encryption in transit, role-based access |
| Public | Marketing content, public API docs | Integrity protection |
A trust boundary exists wherever data crosses between components with different levels of trust. Every crossing must be validated.
Client ←→ API Gateway (user-controlled → server-controlled)
API Gateway ←→ Backend Service (internet-facing → internal)
Backend Service ←→ Database (application → data store)
Service ←→ External API (internal → third-party)
Browser ←→ Browser Extension (page context → extension context)
Main Thread ←→ Web Worker (different execution contexts)
At each boundary crossing:
For detailed lookup tables and code examples, consult:
references/crypto-algorithms.md — Algorithm selection table (recommended vs. deprecated) and common crypto anti-pattern code examplesreferences/architectural-anti-patterns.md — Common security architecture anti-patterns (implicit trust, single points of failure, insecure defaults, monolithic auth) with fixesArchitecture security review directly feeds into the threat modeling process:
When conducting architecture review, consider whether the findings warrant engaging the AppSec team (#team-eng-appsec) for a full threat modeling session.