Application Programming Interface Security and Architecture Questions

Design and implementation of secure application programming interfaces and service interfaces, covering architecture, design patterns, and operational controls across monoliths, microservices, and service mesh environments. Topics include authentication and authorization patterns for endpoints such as OAuth two, application programming interface keys, and JavaScript Object Notation Web Tokens; token and key lifecycle and secure storage; mutual Transport Layer Security for service to service authentication; gateway and proxy based controls and hardening; input validation, schema and contract validation, output encoding, parameter filtering, and secure error handling to prevent injection, parameter pollution, and excessive data exposure. Also covers rate limiting, throttling, and anomaly detection to mitigate abuse and credential stuffing; secure transport and encryption in transit and at rest; design of internal versus external trust boundaries; application programming interface discovery and inventory; threat modeling and mitigations for common application programming interface attacks; and operational practices including audit logging, monitoring, alerting, automated security testing, continuous validation, and strategies for scaling security across many endpoints and services.

HardTechnical

105 practiced

You must securely integrate several third-party APIs into your platform. Describe a secure integration strategy covering vendor vetting, credential management (per-tenant credentials, rotation), sandboxing/testing, rate-limiting and circuit-breakers, monitoring for anomalous behavior, contractual SLAs and how to mitigate supply chain risks from third-party compromises.

Sample Answer

Clarifying approach: I treat this as a secure integration lifecycle—select trusted vendors, secure credentials and runtime, test in isolation, protect availability, continuously monitor, and contractually assign responsibilities including supply-chain controls.

Vendor vetting- Require evidence: SOC 2 Type II, ISO 27001, penetration-test reports, vulnerability disclosure program, recent third‑party risk assessment.- Ask for SBOMs, dependency scanning, secure development lifecycle (SDLC) docs, and MFA for vendor admin access.- Perform a risk score (data sensitivity, blast radius, business criticality) to determine controls and approval gates.

Credential management (per-tenant, rotation)- Use a centralized secrets vault (HashiCorp Vault/AWS Secrets Manager) with HSM-backed KMS for root keys.- Provision per-tenant credentials or scoped OAuth2 client credentials; avoid shared global keys.- Issue short-lived/ephemeral tokens (OAuth2 client credentials with TTL, mTLS certs rotated automatically).- Enforce least privilege on API scopes and use role-bound service identities.- Automate rotation via CI/CD and secrets lifecycle policies; log and alert rotation failures.

Sandboxing & testing- Maintain isolated dev/test sandboxes and mock/stub providers. Use vendor-provided sandboxes where available.- Run contract tests, fuzzing, and gray-box pen tests against integrations before prod onboarding.- Use canary deployments and feature flags to limit exposure.

Rate-limiting & circuit-breakers- Front integrations with API gateway (WAF + rate-limits, per-tenant quotas, token bucket) and implement client-side and server-side backoff.- Implement circuit-breaker patterns (e.g., Hystrix-like) to fail fast and degrade gracefully; auto-retry with exponential backoff and jitter.- Throttle costly operations and provide queueing with visibility.

Monitoring & anomalous behavior- Ingest telemetry: request/response headers, latency, error codes, volume per tenant, credential usage, geo.- Apply anomaly detection (statistical baselines, UEBA) to detect spikes, exfil patterns, credential misuse.- Correlate logs with SIEM, create automated playbooks (block IP, revoke credential) and alert on deviations.- Audit trails, immutable logs, and regular reconciling of vendor-side access.

Contractual SLAs & supply-chain risk mitigation- Negotiate SLAs for availability, data integrity, breach notification timelines, forensic support, and liabilities.- Require incident response playbook, regular exercises, and right-to-audit clauses.- Mitigate supply-chain risk by: vendor diversity for critical services, least-trust allowlists, requiring signed binaries and SBOMs, and monitoring vendor advisories.- Prepare rollback and replacement plans; maintain air-gapped backup of critical data where appropriate.- Insist on cyber insurance and escrow for critical code or data if vendor is strategic.

Operationalizing controls- Automate onboarding checklist, continuous vendor posture scans, periodic reassessments, and breach drills.- Measure: MTTR for incident, mean time to rotate compromised creds, % of integrations with per-tenant creds, and SLA compliance.

This strategy reduces risk across confidentiality, integrity, and availability while enabling scalable third‑party integration.

EasyTechnical

150 practiced

What is an API gateway and what security controls does it typically provide? List and explain at least five security capabilities (for example: authentication, authorization, rate limiting, input validation, TLS termination) and discuss which responsibilities are best centralized at the gateway versus enforced within downstream services.

MediumTechnical

100 practiced

You must design an API versioning and deprecation policy for both public and internal APIs. Discuss versioning schemes (URL path, header, content negotiation), backward-compatibility guarantees, deprecation notices and sunset headers, SDK handling and deprecation cycles, and CI checks to prevent accidental breaking changes. Include security-specific concerns when changing auth or permission models.

Sample Answer

**Approach & goals**Design a predictable, secure versioning/deprecation policy that minimizes risk, preserves compatibility, and gives clients time to migrate—while ensuring auth/permission changes don’t open vulnerabilities.

**Versioning schemes**- URL path (e.g., /v1/...): simple, cache-friendly; use for public stable surface.- Header versioning (e.g., X-API-Version): good for internal/experimental; avoids URI churn.- Content negotiation (Accept header): for feature-level changes; avoid for critical auth changes.

Recommendation: public APIs use URL path versions; internal APIs may use header/version negotiation to allow faster iteration.

**Backward-compatibility guarantees**- PATCH: fully backward-compatible.- MINOR: additive, backward-compatible (new endpoints/fields).- MAJOR: breaking; require explicit migration plan, security review, and staged rollout.Document guarantees in an API contract; require automated integration tests for declared compatibility.

**Deprecation notices & sunset**- Add Deprecation and Sunset response headers: - Deprecation: date and link to migration docs - Sunset: final removal date- Send advance notices: 90 days for internal, 6–12 months for public depending on impact.- Publish changelog, mailing list, dashboard telemetry for impacted consumers.

Example headers:- Deprecation: Wed, 01 Jul 2026 00:00:00 GMT- Sunset: Wed, 01 Jan 2027 00:00:00 GMT- Link: <https://api.example.com/migrate/v2>; rel="migration"

**SDK handling & deprecation cycles**- Ship SDKs pinned to major API versions; deprecate SDK versions following same timeline.- Create automated migration guides and codemods.- Add runtime warnings in SDKs when calling deprecated endpoints.- Maintain LTS SDK for critical security integrations longer; provide security-only patches post-deprecation window.

**CI checks to prevent accidental breaks**- Contract tests (PACT/OpenAPI) enforcing schema and auth expectations.- Automated backward-compatibility diffing (OpenAPI diff) on PRs; block changes that remove fields/endpoints without MAJOR bump.- Fuzzing and security regression tests for auth/permission changes.- Canary deploys + telemetry assertions to detect behavior drift.

**Security-specific concerns**- Auth/permission model changes are breaking by nature; treat as MAJOR: - Require threat model and impact analysis in PR. - Maintain dual-support mode where old tokens remain valid but limited, with logging and elevated alerts. - Rotatable keys and forced re-auth flows documented; use short-lived tokens and JWT claim versioning. - CI must run permission matrix tests ensuring least privilege still enforced. - Notify customers early with clear steps to reconfigure clients; provide automated token migration tooling where possible.

**Trade-offs**- URL versions are explicit but cause SDK churn. Header negotiation enables graceful evolution but is harder to cache and debug.- Longer deprecation windows reduce risk but increase maintenance burden—balance with telemetry-driven sunset.

This policy balances reliability, developer experience, and security controls appropriate for a cybersecurity engineering role.

HardTechnical

93 practiced

Design an automated emergency revocation and credential rotation plan for compromised client credentials affecting thousands of clients. Include detection triggers, mass-revocation mechanics, phased rotation, client notification strategies, fallback modes to preserve critical functionality, and automated rollback if revocations cause unintended outages.

Sample Answer

**Situation / Goal**I would design an automated incident playbook to revoke and rotate compromised client credentials at scale while preserving critical service availability and enabling safe rollback.

**Detection Triggers**- High-confidence signals: leaked credentials in threat intel feeds, anomalous token use (geographic spikes, impossible travel), sudden surge in auth failures, or IDS alerts correlated to client IDs.- Thresholds (example): auth success rate drop >10% and concurrent error spike >5% per minute for >3 minutes → auto-escalate.

**Mass-Revocation Mechanics**- Centralized revocation service: maintain token blacklist + short-lived signing keys + CRL/OCSP endpoints for long-lived certs.- Immediate action: mark compromised credential IDs as revoked in auth DB, publish to distributed caches and WAFs, and push deny rules to API gateways.- Use feature-flagged orchestration (Ansible/Runbooks + K8s jobs) to avoid manual change churn.

**Phased Rotation**- Phase 0: Quarantine affected credential cohort (no full block): route through strict rate-limits and additional step-up auth.- Phase 1 (Canary): revoke & rotate for 1% of affected clients; monitor health and SLOs for 15–30 minutes.- Phase 2: 10% → 50% → 100%, with exponential backoff and verification gates.- Rotation methods: automated issuance via client provisioning API, SDK auto-fetch logic for new creds, fallback short-lived tokens to maintain session continuity.

**Client Notification & Support**- Push notifications via in-band headers, email, and vendor portal with rotation instructions and SDK update links.- Provide one-click provisioning links, grace tokens valid for a short window, and dedicated incident support channel (Slack/phone).- Embed clear rollback/mitigation steps in runbook for external vendors.

**Fallback Modes to Preserve Critical Functionality**- Read-only or degraded mode for affected services if write operations depend on rotated creds.- Allow emergency scoped tokens limited by scope/ACLs to maintain essential telemetry and controls.- Circuit breakers that allow a percentage of traffic through legacy creds only to essential endpoints.

**Automated Rollback**- Continuous health checks: auth error rate, latency, business KPI (transactions/min).- Rollback triggers: sustained SLO breach beyond threshold (e.g., 3× error baseline for 10 minutes) or >X% customer-reported failures.- Rollback mechanism: feature-flag toggle to re-enable previous keys/whitelisted clients, automated reconciliation, and alerting for human approval if rollback occurs.

**Post-incident & Governance**- Automated audit logs, postmortem checklist, update credential policies (shorten TTLs, enforce key rotation), and tabletop exercises.- Metrics: time-to-detect, time-to-revoke, time-to-rotate, customer-impact percentage, rollback occurrences.

I would lead cross-functional runbook drills to validate each step, tune thresholds from production telemetry, and ensure the automation has manual override and clear auditability.

EasyTechnical

95 practiced

Explain Cross-Origin Resource Sharing (CORS): the headers involved (Access-Control-Allow-Origin, -Methods, -Headers, -Credentials), the browser enforcement model, what security guarantees CORS provides (and what it does not), and how to safely configure CORS on APIs that use cookies or bearer tokens.

Sample Answer

**Brief definition**CORS is a browser-enforced HTTP mechanism that lets servers declare which origins may access resources via cross-origin requests. It is a browser policy, not a network firewall.

**Key headers**- Access-Control-Allow-Origin: origin or * — which origin may read responses.- Access-Control-Allow-Methods: allowed HTTP methods for the resource.- Access-Control-Allow-Headers: allowed custom/request headers.- Access-Control-Allow-Credentials: true/false — whether browser may send/accept credentials (cookies, HTTP auth).

Also: Origin (request), Access-Control-Request-Method/Headers (preflight), and Access-Control-Expose-Headers.

**Browser enforcement model**- Browser sends Origin on cross-origin requests.- Simple requests may be allowed/blocked based on response headers.- Non-simple requests trigger a preflight OPTIONS request; server must approve method/headers.- Only browser-enforced: servers and non-browser clients are unaffected.

**Security guarantees and limits**- Guarantees: prevents malicious web pages from reading cross-origin responses unless the target opts in. Protects user data in browser context.- Does NOT: authenticate requests, prevent CSRF, stop server-to-server requests, or protect non-browser clients.

**Safe configuration for cookies / bearer tokens**- Prefer Authorization: Bearer tokens in headers; avoid relying on cookies if possible.- If using cookies: - Set Access-Control-Allow-Credentials: true. - Return a specific Access-Control-Allow-Origin value — never "*". - Use SameSite=strict or lax for session cookies, Secure, and HttpOnly. - Validate Origin server-side against an allowlist and enforce CSRF tokens or same-site protections.- For bearer tokens: - Use short-lived tokens, rotate/refresh securely, validate scopes. - Keep Access-Control-Allow-Credentials false and restrict origins to minimize exposure.

**Best practices**- Implement a server-side origin allowlist and validate Origin header.- Use least-privilege origins and methods.- Combine CORS with CSRF protections and strong authentication/authorization checks server-side.

Unlock Full Question Bank

Get access to hundreds of Application Programming Interface Security and Architecture interview questions and detailed answers.

Join thousands of developers preparing for their dream job.