SWE II > Security > Flashcards

Security Flashcards

(110 cards)

Study These Flashcards
1
Q

AuthN vs AuthZ

A

Authentication (AuthN) = who you are (validate identity). Authorization (AuthZ) = what you are allowed to do (enforce permissions on actions/resources).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

CIA triad

A

Confidentiality (prevent data leaks), Integrity (prevent unauthorized changes), Availability (keep service usable). Security decisions usually trade off among these.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Least privilege

A

Grant only the minimum permissions needed (IAM policies, DB roles, app permissions). Reduce blast radius if credentials are leaked.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Trust boundary

A

A point where data crosses from a less-trusted zone to a more-trusted one (client→API, service→service, API→DB). Re-validate/authorize at each boundary.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Defense in depth

A

Use multiple independent layers (network controls + IAM + app authz + validation + logging). Assume one layer can fail.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

What is OWASP Top 10 used for?

A

A reference list of common web app/API risk categories (e.g., broken access control, injection, misconfiguration). Useful as a checklist for reviews.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Broken Access Control (example)

A

IDOR: user accesses /accounts/123 and can see another user’s data by guessing IDs. Fix: authorize access to the specific resource (ownership/tenant checks).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

IDOR prevention

A

Never trust only the resource ID. Always check ownership/tenant match server-side. Prefer opaque IDs when possible (still must authorize).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

SQL injection prevention

A

Use parameterized queries/prepared statements. Avoid string concatenation for SQL. Validate/allowlist dynamic sort fields and column names.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Sensitive data exposure prevention

A

TLS for in-transit, encryption at rest, strict access controls, minimize data returned, avoid logging secrets/PII, and strong key management.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Security misconfiguration examples

A

Publicly accessible databases, overly permissive security groups, default credentials, verbose error pages, missing security headers.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

SSRF (what is it?)

A

Server-Side Request Forgery: attacker makes your server fetch internal/privileged URLs (metadata endpoints, internal services). Prevent with allowlists, egress controls, and URL validation.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Input validation principle

A

Validate at boundaries (controller DTO validation + business rules). Prefer allowlists over blocklists (e.g., enum values).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Do not trust client claims

A

Never accept roles/tenant IDs from request body; derive them from the validated token or server-side lookup.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Encryption in transit

A

Use HTTPS/TLS for client↔API and ideally TLS/mTLS for service↔service in sensitive environments.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Encryption at rest

A

Encrypt DB/storage (e.g., RDS encryption, EBS, S3 SSE). Ensure backups and snapshots are encrypted too.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Token vs session (high level)

A

Sessions often use cookies and server-side state; tokens (JWT) are usually stateless and validated on each request.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

JWT is not encrypted

A

JWT payload is Base64URL-encoded, not encrypted by default. Never put secrets in JWT claims.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

JWT must-validate checklist

A

Validate signature, expiration (exp), issuer (iss), audience (aud), and token not-before (nbf) if used. Reject tokens with weak/none algorithms.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

JWT key rotation

A

Use key IDs (kid) and rotate signing keys. Services should fetch keys from a JWKS endpoint and cache with TTL.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

OAuth2 in one sentence

A

A framework for delegated authorization. APIs often act as ‘resource servers’ validating access tokens issued by an Identity Provider.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Scopes vs roles

A

Scopes are typically OAuth2 permissions for an app/client (e.g., read:orders). Roles are user/group permissions. Many systems map both into authorities.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Access token vs refresh token

A

Access token: short-lived, used on requests. Refresh token: longer-lived, used to obtain new access tokens (should be stored/handled very carefully).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Why short-lived tokens?

A

Limits damage if token is stolen. Combine with rotation and revocation strategies where needed.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Replay attack (API)
An attacker reuses a captured request/token. Mitigate with TLS, short token TTLs, nonce/idempotency keys for sensitive operations, and server-side checks.
26
Idempotency key
A client-provided key used so the server can safely handle retries without duplicating side effects (e.g., payments). Store key + result for a time window.
27
CORS (what is it?)
A browser security mechanism controlling cross-origin requests. It’s not an API security control by itself; servers still must authenticate/authorize.
28
CORS best practice
Allow only required origins, methods, and headers. Avoid wildcard origins for authenticated endpoints.
29
CSRF (what is it?)
Cross-Site Request Forgery: attacker causes a user's browser to send authenticated requests. Relevant for cookie-based auth; less so for pure token-in-header APIs.
30
CSRF mitigation
Use CSRF tokens for cookie sessions, SameSite cookies, and avoid state-changing GETs.
31
Spring Security: common approach for APIs
Configure Spring Boot as a resource server to validate JWTs, enforce authentication on endpoints, and use method/URL authorization rules.
32
Constructor injection and security
Constructor injection makes dependencies explicit and testable (including security-related services like authorization checks).
33
Method-level authorization benefit
Enforcing authz in the service layer protects reused code paths and reduces reliance on controller-only checks.
34
Example: RBAC
Role-based access control: roles like ADMIN/USER. Simple but can be too coarse for multi-tenant ownership rules.
35
Example: ABAC
Attribute-based access control: policies based on attributes like tenantId, department, resource ownerId. More flexible and safer for multi-tenant.
36
Multi-tenant golden rule
Always enforce tenant isolation server-side. Every query should be scoped by tenantId derived from the token/context.
37
Tenant ID source
Prefer tenantId from validated token claims or server-side session context, not user input.
38
Object-level authorization
Authorization based on a specific resource instance (e.g., user can read order only if order.ownerId == user.id).
39
Centralized error handling (security)
Return consistent errors (401/403/400) without leaking stack traces. Log internal details with correlation IDs.
40
401 vs 403
401 Unauthorized = not authenticated/invalid token. 403 Forbidden = authenticated but lacks permission.
41
Security logging rule
Never log passwords, tokens, secret keys. Mask sensitive fields. Use correlation IDs for tracing.
42
Rate limiting purpose
Protects against brute force and abuse; improves availability. Apply to login endpoints and expensive operations.
43
Brute force login mitigation
Rate limit, lockout with care, CAPTCHA/MFA if applicable, and monitor suspicious patterns.
44
Password hashing best practice
Use bcrypt/scrypt/Argon2; never store plaintext. Do not use fast hashes like SHA-256 for passwords.
45
Why bcrypt/Argon2?
They are slow and resistant to brute-force (cost factor), making stolen hashes harder to crack.
46
Secure password reset
Use one-time, time-limited tokens. Don’t reveal whether an email exists. Invalidate tokens after use.
47
Principle of fail-safe defaults
Default deny: if you’re unsure, reject the request. Explicitly allow only what is necessary.
48
Security headers (high-level)
Use headers like HSTS, X-Content-Type-Options, Content-Security-Policy (web), and set correct cache headers for sensitive data.
49
Data minimization
Return only necessary fields in API responses. Use DTOs; avoid exposing internal entity models.
50
Avoid verbose error messages
Do not return internal exception details to clients. Provide a stable error code and message; log details internally.
51
Dependency vulnerabilities
Keep libraries updated. Use dependency scanning (SCA) in CI to detect known CVEs.
52
SAST vs DAST
SAST scans source/bytecode for patterns; DAST tests the running app. Both are complementary.
53
Secret scanning
Use tooling (GitHub secret scanning, pre-commit hooks) to prevent committing credentials.
54
Where should secrets live?
In a secret manager (AWS Secrets Manager / SSM Parameter Store) or CI secret store; injected at runtime.
55
AWS IAM: user vs role
Prefer roles for workloads (EC2 instance profile, ECS task role, Lambda role). Avoid long-lived access keys.
56
AWS IAM policy scope
Limit actions and resources (ARNs). Avoid '*'. Use condition keys when possible.
57
Security groups
Stateful firewall rules attached to instances/ENIs. Allow least required inbound/outbound.
58
NACLs
Stateless subnet-level rules. Typically a second layer; security groups are primary in many setups.
59
Public vs private subnets
Public: route to Internet Gateway. Private: no direct inbound from internet; use NAT for outbound if needed.
60
Database exposure best practice
Keep DB in private subnets; restrict inbound to app security group only; avoid public endpoints.
61
Encryption in RDS (concept)
Enable storage encryption and enforce TLS connections where supported; rotate credentials regularly.
62
S3 security basics
Block public access by default, use bucket policies carefully, enable encryption (SSE), and least privilege IAM access.
63
mTLS (what is it?)
Mutual TLS: both sides present certificates. Strengthens service-to-service authentication inside a network.
64
Timeouts are security too
Timeouts prevent resource exhaustion and cascading failures; they also reduce attack surface for slow-loris style abuse.
65
Retries: safe use
Retry only idempotent operations and use exponential backoff + jitter. Cap retries to avoid thundering herds.
66
Circuit breaker purpose
Stops repeated calls to failing dependencies, preventing cascades and improving availability.
67
Audit logging (what to capture)
Who did what and when: actor, action, target resource ID, outcome, traceId—without sensitive payloads.
68
PII handling principle
Collect/store the minimum needed; restrict access; encrypt; redact in logs; comply with retention policies.
69
Data retention
Keep data only as long as needed; define retention and deletion policies (important for compliance).
70
Secure file uploads
Validate content type, limit size, scan for malware, store outside web root, use random filenames, and restrict access.
71
Content-type validation risk
Relying only on file extension is unsafe. Validate MIME type and/or inspect file headers (magic bytes).
72
Open redirect risk
Avoid redirecting to user-supplied URLs. Use allowlists or relative paths.
73
Clickjacking (web)
Prevent embedding with headers (X-Frame-Options / CSP frame-ancestors). Mostly relevant for web UIs.
74
Deserialization risk
Avoid unsafe deserialization of untrusted data. Prefer JSON libraries with safe configs; do not deserialize arbitrary objects.
75
HTTP security: safe methods
Avoid state changes via GET. Use POST/PUT/PATCH/DELETE for mutations. Helps prevent CSRF-like issues and caching surprises.
76
Authentication at gateway vs service
Gateway can authenticate, but services should still authorize (and sometimes re-validate tokens) depending on architecture.
77
Service-to-service auth options
JWT with service identities, mTLS, or signed requests. Choose based on threat model and platform capabilities.
78
RBAC pitfall
Role explosion or overly broad roles. Consider permissions/ABAC for fine-grained access.
79
Authorization caching pitfall
Caching permissions can cause stale auth decisions. If caching, keep TTL short and design for revocation.
80
JWT revocation challenge
Stateless tokens are hard to revoke immediately. Use short TTLs, refresh tokens, and optionally token introspection/deny lists.
81
Principle of secure by default
New endpoints should require auth by default; explicit exceptions only (e.g., health checks).
82
Least privilege for DB accounts
Use separate DB users/roles per service with minimal permissions; avoid using superuser accounts.
83
Protect against mass assignment
Bind only allowed fields in request DTOs; don’t map arbitrary JSON into entities without controls.
84
Mass assignment example
If API accepts user JSON and maps directly to entity, attacker may set isAdmin=true. Fix: DTO allowlist fields.
85
Prevent information disclosure in 404
Don’t reveal whether a resource exists if user lacks access. Consider returning 404 instead of 403 for some resources (policy-driven).
86
Security testing: what to add
Unit tests for authz rules, integration tests for 401/403 flows, and regression tests for known vulnerabilities.
87
Threat modeling (basic)
Identify assets, entry points, trust boundaries, attackers, and mitigations. Use it to guide security priorities.
88
What is a security incident?
An event that compromises confidentiality, integrity, or availability (e.g., data leak, account takeover, ransomware).
89
Incident response priorities
Containment/mitigation first, then root cause, then prevention (patches, monitoring, postmortem action items).
90
Logging for incident response
Keep enough context (traceId, actor, action) to investigate, but avoid storing secrets/PII unnecessarily.
91
Principle of separation of duties
Separate permissions for deploy, admin actions, and data access. Reduce risk of single credential compromise.
92
Secure defaults for Spring endpoints
Require authentication for all routes, explicitly permit only public endpoints, and avoid exposing actuator endpoints publicly.
93
Actuator endpoint security
Protect Actuator with auth and network restrictions; expose only required endpoints; avoid leaking env/config.
94
Avoid hard-coded crypto
Use proven libraries and platform features. Don’t implement your own encryption or token signing.
95
Salt vs pepper (passwords)
Salt is per-user and stored with hash; pepper is a secret global value stored separately. Many systems only use salt via bcrypt/Argon2.
96
Why use constant-time compares?
To reduce timing attacks when comparing secrets/tokens. Many libs provide safe comparison methods.
97
Secure pagination/filtering
Avoid exposing unrestricted queries. Add limits, validate sort fields, and protect against expensive filters.
98
DoS protection basics
Rate limiting, request size limits, timeouts, circuit breakers, and resource quotas.
99
Secure configuration management
Separate config from code, use profiles, validate required settings, and avoid secrets in config files.
100
Key management basics
Rotate keys, limit access, audit usage, and use managed KMS where possible.
101
KMS in one sentence
AWS Key Management Service manages encryption keys and allows controlled encrypt/decrypt operations with auditing.
102
Audit vs application logs
Audit logs track security-relevant actions; application logs track operational behavior. Both should be correlated via traceId.
103
Security reviews: checklist items
AuthN/AuthZ, input validation, data exposure, logging redaction, dependency updates, least privilege, and safe defaults.
104
Common security code smells
String-built SQL, direct entity exposure, trusting request-provided roles/tenantId, logging tokens, and public resources by default.
105
If you can only do 3 security things
1) Strong AuthN/AuthZ with ownership checks, 2) Secure secrets + least privilege, 3) Good observability (logs/metrics) with redaction.
106
What is 'authentication at the edge'?
Performing authentication at an API gateway/load balancer layer. Still ensure services enforce authorization and don’t trust unauthenticated internal traffic.
107
Why separate environments (dev/staging/prod) for security?
Limits exposure and reduces risk. Prod should have strict access, secrets, and logging; dev should not share prod credentials.
108
How to handle 3rd-party API keys securely?
Store in secret manager, rotate regularly, scope permissions if possible, and avoid logging them.
109
How do you secure admin endpoints?
Require strong auth, separate roles, consider network restrictions, and log/audit all admin actions.
110
What is 'secure coding' in one sentence?
Writing code that assumes inputs can be hostile, enforces access control consistently, protects data, and fails safely.
SWE II
flashcards
Decks in class (10)
# Cards
Brainscape helps you reach your goals faster, through stronger study habits.
© 2026 Bold Learning Solutions. Terms and Conditions