{"data":{"id":"SP-030","slug":"api-security","title":"API Security","description":"Comprehensive security pattern for protecting application programming interfaces across their full lifecycle. Maps 45 NIST 800-53 controls to the critical security functions required to defend APIs against the OWASP API Security Top 10: authentication, authorization, input validation, rate limiting, transport security, inventory management, and continuous monitoring.","url":"https://www.opensecurityarchitecture.org/patterns/sp-030","metadata":{"release":"26.02","classification":"Application Security","status":"active","type":"pattern","datePublished":"2026-02-06","dateModified":"2026-02-06","authors":["Aurelius","Vitruvius"],"reviewers":[],"provenance":"Derived from securing API-first architectures in financial services, where payment APIs, open banking interfaces, and partner integrations create high-value attack surfaces. Informed by OWASP API Security Top 10, NIST SP 800-204 series on microservices security, and practical experience with API gateways, OAuth 2.0 deployments, and API abuse detection at scale."},"diagram":{"svg":"/images/sp-030-api-security.svg","png":""},"content":{"description":"APIs are the connective tissue of modern software architecture. Every microservice, mobile application, SaaS integration, partner onboarding flow, and IoT device communicates through APIs. This expansion of the API attack surface means that API security is no longer an afterthought bolted onto web application controls -- it is a primary security discipline requiring purpose-built architecture.\n\nTraditional web application firewalls are insufficient for API security because APIs expose structured data and business logic, not rendered web pages. Attacks against APIs target authentication mechanisms, authorization logic, data exposure, rate limiting gaps, and business process abuse -- threats that require controls operating at the application semantics layer, not just the network layer.\n\nThis pattern defines the architectural controls required to secure APIs across four layers: an API Gateway that enforces authentication, rate limiting, and schema validation at the edge; an Authorization Layer that makes fine-grained access decisions based on OAuth scopes, roles, and resource ownership; a Validation Layer that sanitises all input against defined schemas before it reaches business logic; and a Monitoring Layer that detects anomalous usage patterns, credential abuse, and data exfiltration in real-time.\n\nThe pattern covers the full API lifecycle: secure design (threat modelling, schema-first development), secure development (input validation, output filtering, error handling), secure deployment (gateway configuration, TLS enforcement, rate limiting), and secure operations (monitoring, incident response, deprecation). It applies equally to REST, GraphQL, gRPC, WebSocket, and event-driven API styles.","keyControlAreas":["API Authentication and Identity Management (IA-02, IA-04, IA-05, IA-08, IA-09): Every API call must be authenticated. IA-02 mandates identification and authentication for organisational users accessing APIs, requiring OAuth 2.0 bearer tokens, API keys with HMAC signing, or mutual TLS certificates rather than basic authentication over plain HTTP. IA-04 manages the lifecycle of API credentials: provisioning, rotation, suspension, and revocation of API keys and client IDs. IA-05 governs authenticator management -- token signing key rotation, API key entropy requirements, and credential storage using secrets managers rather than embedded in source code or configuration files. IA-08 extends authentication to non-organisational users: third-party developers, partner integrations, and public API consumers who authenticate via OAuth client credentials, API keys, or federated identity. IA-09 addresses service-to-service authentication -- the critical requirement that internal APIs between microservices use mutual TLS, service mesh identity (SPIFFE/SPIRE), or signed JWTs rather than relying on network-level trust. Implementation requires centralised API key management, short-lived token issuance (15-minute access tokens with refresh rotation), and automated credential rotation with zero-downtime deployment.","API Authorization and Access Control (AC-03, AC-04, AC-06, AC-07, AC-10, AC-12): Authorization in API security must operate at multiple granularities: endpoint level, resource level, field level, and operation level. AC-03 enforces access based on OAuth 2.0 scopes, RBAC roles, or ABAC policies -- critically, authorization must check not just whether the authenticated identity can access the endpoint, but whether it can access the specific resource instance (preventing Broken Object Level Authorization, OWASP API #1). AC-04 controls information flow between API boundaries, preventing APIs from leaking data across trust domains or returning more data than the consumer is authorised to see. AC-06 enforces least privilege: API tokens should carry the minimum scopes required for the specific operation, not blanket admin access. AC-07 limits unsuccessful authentication attempts with progressive rate limiting and account lockout to prevent credential stuffing against API authentication endpoints. AC-10 controls concurrent API sessions to prevent token farming and session multiplication attacks. AC-12 enforces token expiration and session termination -- access tokens must have short lifetimes, refresh tokens must be rotation-bound, and revocation must propagate to all enforcement points within seconds.","API Gateway and Boundary Protection (SC-07, AC-17, AC-20, AC-21): The API gateway is the primary security enforcement point for all API traffic. SC-07 enforces boundary protection: the gateway terminates TLS, validates authentication tokens, applies rate limits, checks schema compliance, and routes only validated requests to backend services. No API consumer should ever communicate directly with backend services -- all traffic flows through the gateway. AC-17 governs remote access to APIs, ensuring that API endpoints exposed to the internet have defence-in-depth controls: WAF integration, DDoS protection, geographic restrictions where appropriate, and IP reputation filtering. AC-20 controls the use of external APIs that the organisation consumes -- third-party API dependencies must be inventoried, risk-assessed, and monitored for availability, security incidents, and breaking changes. AC-21 enables controlled information sharing via APIs while enforcing data classification policies: public endpoints return only public data, partner endpoints enforce contractual data boundaries, and internal endpoints may return richer data but only to authenticated internal services.","Input Validation and Injection Prevention (SI-10, SI-03, SI-11, SI-15): Input validation is the most critical technical control in API security. SI-10 mandates validation of all API input: request parameters, headers, path segments, query strings, and request bodies must be validated against the API schema (OpenAPI, GraphQL schema, protobuf definition) before reaching business logic. This prevents SQL injection, NoSQL injection, command injection, XML external entity attacks, and server-side request forgery. Validation must be allowlist-based (accept known-good) rather than denylist-based (reject known-bad). SI-03 provides malicious code protection at the API layer: scanning uploaded files, detecting encoded payloads, and preventing polyglot attacks that bypass content-type restrictions. SI-11 controls error handling to prevent information leakage -- API error responses must return standardised error codes and messages without exposing stack traces, database schemas, internal paths, or implementation details that aid reconnaissance. SI-15 filters information output to prevent excessive data exposure (OWASP API #3): APIs must return only the fields required by the consumer, implement field-level filtering, and never expose internal identifiers, timestamps, or metadata that the consumer does not need.","Transport Security and Cryptography (SC-08, SC-13, SC-23, SC-28): All API communication must be encrypted in transit and sensitive data encrypted at rest. SC-08 mandates TLS 1.2+ for all API traffic with no fallback to unencrypted HTTP -- this includes internal service-to-service communication, not just external-facing APIs. For service mesh architectures, mutual TLS (mTLS) provides both encryption and service identity verification. SC-13 specifies cryptographic protection for API tokens: JWTs must use asymmetric signing (RS256/ES256, not HS256 with shared secrets), API keys must be generated with sufficient entropy (256-bit minimum), and payload encryption (JWE) should be used for sensitive data in transit. SC-23 ensures session authenticity: API tokens must be bound to the client, protected against replay with short expiration and nonce values, and validated on every request including signature verification, expiration checking, and audience validation. SC-28 protects API data at rest: API logs containing request/response bodies must be encrypted, API key hashes stored rather than plaintext keys, and any API cache or queue containing sensitive data must be encrypted.","API Inventory and Lifecycle Management (CM-02, CM-03, CM-07, CM-08): You cannot secure what you cannot see. CM-08 maintains a real-time inventory of all APIs: every endpoint, version, owner, consumer, authentication method, data classification, and deployment status. Shadow APIs and zombie APIs (deprecated but still accessible) are among the most dangerous attack surfaces. CM-02 establishes baseline configurations for API deployments: standard gateway policies, required security headers (CORS, CSP, HSTS), mandatory TLS versions, and default rate limits. CM-03 controls API changes: schema changes must be versioned, backward-compatible, and deployed through CI/CD with automated contract testing. Breaking changes require consumer notification and migration periods. CM-07 enforces least functionality: disable unused HTTP methods, remove debug endpoints before production deployment, disable GraphQL introspection in production, and decommission deprecated API versions on a published timeline rather than leaving them accessible indefinitely.","API Monitoring and Anomaly Detection (AU-02, AU-03, AU-06, AU-12, CA-07, SI-04): API monitoring must capture both security events and business logic abuse. AU-02 defines auditable API events: all authentication attempts (success and failure), authorisation decisions, rate limit triggers, schema validation failures, and sensitive data access. AU-03 specifies audit record content: timestamp, source IP, authenticated identity, API endpoint, HTTP method, response code, response time, request size, and correlation ID for distributed tracing. AU-06 analyses API audit records to detect patterns: credential stuffing attacks (many failed auths from one IP), broken object level authorization attempts (sequential ID enumeration), data scraping (paginated bulk extraction), and business logic abuse (unusual transaction patterns). AU-12 generates audit records at the API gateway and within backend services, providing end-to-end request tracing. CA-07 provides continuous monitoring of API health, security posture, and compliance. SI-04 monitors API traffic in real-time for anomalies: unusual request volumes, geographic access pattern changes, new user agents, and response size anomalies that may indicate data exfiltration.","API Security Testing and Assessment (CA-02, RA-03, RA-05, SA-08, SA-11): API security must be validated continuously through the development lifecycle. CA-02 provides security assessments of API implementations: penetration testing focused on OWASP API Top 10, fuzzing of all input parameters, and authentication/authorisation bypass testing. RA-03 requires API threat modelling during design: identifying trust boundaries, data flows, authentication points, and potential abuse scenarios before writing code. RA-05 mandates vulnerability scanning: automated DAST tools that test deployed APIs for injection, authentication bypass, and excessive data exposure, integrated into CI/CD pipelines. SA-08 applies security engineering principles to API design: schema-first development with security constraints defined in the API specification, fail-closed authorisation defaults, and defence-in-depth with validation at both gateway and service layers. SA-11 requires developer security testing: unit tests for authorisation logic, contract tests validating schema compliance, and integration tests that verify security controls function correctly across the API stack."],"assumptions":"The organisation develops or consumes APIs as part of its technology stack. An API gateway or reverse proxy capability exists or can be deployed. Development teams follow a schema-first or design-first API development approach (OpenAPI, GraphQL SDL, protobuf). OAuth 2.0 or equivalent token-based authentication infrastructure is available. API consumers can be identified and authenticated (even public APIs should require API keys for rate limiting and abuse tracking). A CI/CD pipeline exists for automated testing and deployment. Logging and monitoring infrastructure can ingest and analyse API traffic at the expected volume.","typicalChallenges":"Legacy APIs that pre-date current security standards resist retrofitting -- they may use basic authentication, lack input validation, or return excessive data in responses. Shadow APIs created by development teams outside governance processes create unknown attack surface. GraphQL APIs with deeply nested queries enable denial-of-service without proper query depth and complexity limits. Versioning strategy disputes slow progress: URL versioning vs header versioning vs content negotiation each have trade-offs. Rate limiting at the right granularity is difficult: too coarse blocks legitimate high-volume consumers, too fine creates operational overhead. API key sprawl across multiple consumers makes rotation and revocation operationally painful without centralised key management. Microservice architectures generate enormous east-west API traffic that is expensive to monitor comprehensively. Documentation drift between API specifications and implementations creates false confidence in security testing. Partner API integrations involve contractual and technical constraints that limit security control options. API deprecation faces resistance when consumers depend on legacy endpoints and migration timelines slip indefinitely.","indications":"This pattern applies to any organisation that exposes or consumes APIs. It is essential for organisations with public-facing APIs accessed by third-party developers, mobile applications that communicate via REST or GraphQL APIs, microservice architectures with significant service-to-service API traffic, open banking or PSD2 compliance requirements, partner integration programmes with API-based data exchange, IoT device fleets communicating via API endpoints, or any architecture where APIs are the primary interface for data access and business logic execution.","contraIndications":"This pattern adds unnecessary overhead for purely internal monolithic applications that do not expose APIs. Organisations with exclusively file-based integrations (SFTP, batch processing) may find limited applicability until they modernise to API-based integration. Very early-stage prototypes may defer comprehensive API security controls, though basic authentication and input validation should never be skipped even in prototypes.","threatResistance":"API Security addresses the OWASP API Security Top 10 and beyond. Broken Object Level Authorization (BOLA/IDOR) is mitigated by resource-level authorization checks at the service layer, not just endpoint-level (AC-03, AC-06). Broken authentication including credential stuffing and API key theft is addressed by strong authenticator management, short-lived tokens, and progressive rate limiting (IA-02, IA-05, AC-07). Excessive data exposure is prevented by field-level output filtering and response schema validation (SI-15, AC-04). Rate limiting bypass and API abuse are controlled by multi-layer throttling at gateway and service levels (AC-07, AC-10, SC-07). Injection attacks through API parameters are blocked by schema-based input validation and allowlist filtering (SI-10, SI-03). Server-side request forgery via API input is prevented by input validation and URL allowlisting (SI-10, SC-07). Mass assignment and parameter tampering are addressed by strict schema validation that rejects unexpected fields (SI-10, AC-03). API supply chain compromise through malicious third-party APIs is mitigated by vendor assessment, monitoring, and circuit-breaker patterns (AC-20, SR-02, SR-03). Man-in-the-middle on API traffic is eliminated by mandatory TLS and certificate pinning for sensitive integrations (SC-08, SC-13). Shadow API exposure is addressed by continuous API inventory and discovery scanning (CM-08, CM-07, RA-05). Token theft and replay attacks are mitigated by short-lived tokens, audience binding, and continuous session validation (SC-23, AC-12, IA-05). API denial of service through resource exhaustion is controlled by rate limiting, query complexity limits, and payload size restrictions (AC-07, SC-07, SI-10)."},"examples":{"Public REST API":["OAuth 2.0 authorization code flow with PKCE for user-facing APIs, client credentials for server-to-server","API gateway enforcing rate limits (1000 req/min per API key), schema validation against OpenAPI spec, and geographic IP filtering","JWT access tokens with 15-minute expiry, RS256 signing, and audience claim validation on every request","Structured error responses with correlation IDs, no stack traces or internal details in production"],"Internal Microservices":["Service mesh (Istio/Linkerd) with mTLS between all services and SPIFFE identity for service authentication","gRPC with protobuf schema validation, automatic payload size limits, and deadline propagation","Internal API gateway for east-west traffic with circuit breakers, retry budgets, and distributed tracing","Service-to-service authorization via short-lived JWTs issued by internal identity provider"],"Partner API Integration":["Dedicated partner API gateway with per-partner rate limits, IP allowlisting, and webhook signature validation","Contractual data boundaries enforced at the API layer: partner tokens scoped to specific resources and operations","Third-party API dependencies monitored for availability, latency degradation, and security advisories","API versioning with 12-month deprecation windows and automated consumer migration notifications"],"GraphQL API":["Query depth limiting (max 10 levels), query complexity scoring with cost-based rate limiting","Field-level authorization: different user roles see different fields on the same type","Persisted queries in production eliminating arbitrary query execution, introspection disabled","Automatic query complexity analysis in CI/CD preventing deployment of expensive resolver patterns"],"Developing Areas":["GraphQL-specific security tooling is significantly less mature than REST API security tooling. While REST APIs benefit from decades of WAF rules, API gateway policies, and DAST scanners, GraphQL's flexible query language creates novel attack vectors (deeply nested queries, alias-based batching, field suggestion enumeration) that most generic API security tools do not handle. Purpose-built GraphQL security solutions like GraphQL Armor and Stellate are emerging, but enterprise-grade GraphQL security -- including field-level authorization, cost-based rate limiting, and query complexity analysis -- still requires substantial custom implementation.","API abuse detection for business logic attacks is an emerging discipline that sits at the intersection of API security and fraud detection. Traditional API security tools focus on technical attacks (injection, authentication bypass), but the most damaging API attacks increasingly exploit business logic -- inventory manipulation, coupon stacking, price scraping, and competitive intelligence harvesting -- that appear as legitimate API usage at the technical level. Detecting these attacks requires understanding business context and establishing behavioural baselines that current API gateway and WAF products are only beginning to support.","Machine-to-machine API authentication at scale is creating credential management challenges that outpace current tooling. As microservice architectures grow to hundreds or thousands of services, each requiring unique credentials for inter-service communication, the volume of API keys, certificates, and tokens becomes operationally unmanageable with manual processes. Service mesh identity (SPIFFE/SPIRE) and workload identity federation are emerging solutions, but adoption requires significant infrastructure investment and most organisations still manage M2M credentials through a mix of secrets managers and manual processes with inconsistent rotation.","API sprawl discovery -- finding undocumented, shadow, and zombie APIs across the enterprise -- is a rapidly developing market driven by the recognition that organisations typically have 3-5x more APIs than they are aware of. API discovery tools that analyse network traffic, code repositories, and cloud configurations to build comprehensive API inventories are emerging from vendors like Noname Security, Salt Security, and Traceable, but the accuracy of automated discovery varies significantly and maintaining a continuously updated API inventory remains operationally challenging.","Runtime API protection that operates independently of the API gateway is an emerging architectural pattern addressing the limitation that gateway-only security cannot detect or prevent business logic attacks, BOLA, or data exposure that depends on application-level context. Inline and sidecar-based runtime protection solutions inspect API traffic with awareness of the application's data model and authorization logic, but they add latency and complexity that creates tension with the performance requirements of high-throughput API architectures."]},"references":[{"title":"OWASP API Security Top 10 (2023)","url":"https://owasp.org/API-Security/","note":"The definitive list of API security risks. Covers broken authentication, broken authorization (BOLA), excessive data exposure, rate limiting, injection, mass assignment, security misconfiguration, and more. Essential reading for any API security programme."},{"title":"NIST SP 800-204: Security Strategies for Microservices-based Application Systems","url":"https://csrc.nist.gov/publications/detail/sp/800-204/final","note":"NIST guidance on securing microservices architectures including API gateways, service mesh security, and inter-service authentication patterns."},{"title":"NIST SP 800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture","url":"https://csrc.nist.gov/publications/detail/sp/800-204a/final","note":"Detailed guidance on service mesh security including mTLS, service identity, and API traffic monitoring within microservice deployments."},{"title":"NIST SP 800-53 Rev 5: Security and Privacy Controls","url":"https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final","note":"The control catalogue referenced throughout this pattern. Rev 5 controls map directly to API security functions."},{"title":"RFC 6749: The OAuth 2.0 Authorization Framework","url":"https://datatracker.ietf.org/doc/html/rfc6749","note":"The foundational specification for API authentication and authorization. Supplemented by RFC 7636 (PKCE), RFC 7519 (JWT), and RFC 8725 (JWT best practices)."},{"title":"OpenAPI Specification 3.1","url":"https://spec.openapis.org/oas/v3.1.0","note":"The standard for API description. Schema-first API development using OpenAPI enables automated validation, testing, and documentation generation."},{"title":"OWASP Web Security Testing Guide: API Testing","url":"https://wstg.owasp.org/latest/4-Web_Application_Security_Testing/12-API_Testing/","note":"The API testing chapter of OWASP's Web Security Testing Guide: API reconnaissance, broken object-level and function-level authorization, excessive data exposure, and GraphQL. The guide's other chapters cover authentication, authorization, injection and business logic testing."},{"title":"Google API Design Guide","url":"https://cloud.google.com/apis/design","note":"Google's API design principles including security considerations. Demonstrates production-proven patterns for authentication, error handling, and versioning at scale."}],"relatedPatterns":["SP-002","SP-004","SP-005","SP-008","SP-011","SP-016","SP-028","SP-029"],"relatedPatternNames":["Server Module","SOA Publication and Location","SOA Internal Service Usage","Public Web Server","Cloud Computing","DMZ Module","Secure DevOps Pipeline","Zero Trust Architecture"],"threats":[{"id":"T-API-001","name":"Broken authentication and credential stuffing","mitigatedBy":["IA-02","IA-05","AC-07","SI-04"]},{"id":"T-API-002","name":"Broken object level authorization (BOLA/IDOR)","mitigatedBy":["AC-03","AC-06","AU-06","SI-04"]},{"id":"T-API-003","name":"Injection attacks via API parameters","mitigatedBy":["SI-10","SI-03","SI-11","AC-04"]},{"id":"T-API-004","name":"Excessive data exposure in API responses","mitigatedBy":["SI-15","AC-04","AC-06","AU-06"]},{"id":"T-API-005","name":"Rate limiting bypass and API abuse","mitigatedBy":["AC-07","AC-10","SC-07","SI-04"]},{"id":"T-API-006","name":"Mass assignment and parameter tampering","mitigatedBy":["SI-10","AC-03","CM-02","SA-08"]},{"id":"T-API-007","name":"Server-side request forgery via API input","mitigatedBy":["SI-10","SC-07","AC-04","SI-03"]},{"id":"T-API-008","name":"Third-party API supply chain compromise","mitigatedBy":["AC-20","SR-02","SR-03","SI-04"]},{"id":"T-API-009","name":"Man-in-the-middle on API traffic","mitigatedBy":["SC-08","SC-13","SC-23","IA-09"]},{"id":"T-API-010","name":"Shadow API and zombie API exposure","mitigatedBy":["CM-08","CM-07","RA-05","CA-07"]},{"id":"T-API-011","name":"Token theft and replay attacks","mitigatedBy":["SC-23","AC-12","IA-05","SI-04"]},{"id":"T-API-012","name":"API denial of service via resource exhaustion","mitigatedBy":["AC-07","SC-07","SI-10","CA-07"]}],"controls":[{"id":"AC-03","name":"Access Enforcement","family":"AC","emphasis":"critical"},{"id":"AC-04","name":"Information Flow Enforcement","family":"AC","emphasis":"critical"},{"id":"AC-06","name":"Least Privilege","family":"AC","emphasis":"critical"},{"id":"AC-07","name":"Unsuccessful Logon Attempts","family":"AC","emphasis":"critical"},{"id":"AC-10","name":"Concurrent Session Control","family":"AC","emphasis":"standard"},{"id":"AC-12","name":"Session Termination","family":"AC","emphasis":"important"},{"id":"AC-17","name":"Remote Access","family":"AC","emphasis":"important"},{"id":"AC-20","name":"Use of External Systems","family":"AC","emphasis":"important"},{"id":"AC-21","name":"Information Sharing","family":"AC","emphasis":"important"},{"id":"AT-02","name":"Literacy Training and Awareness","family":"AT","emphasis":"standard"},{"id":"AT-03","name":"Role-based Training","family":"AT","emphasis":"standard"},{"id":"AU-02","name":"Event Logging","family":"AU","emphasis":"critical"},{"id":"AU-03","name":"Content of Audit Records","family":"AU","emphasis":"important"},{"id":"AU-06","name":"Audit Record Review, Analysis, and Reporting","family":"AU","emphasis":"important"},{"id":"AU-12","name":"Audit Record Generation","family":"AU","emphasis":"important"},{"id":"CA-02","name":"Control Assessments","family":"CA","emphasis":"important"},{"id":"CA-07","name":"Continuous Monitoring","family":"CA","emphasis":"critical"},{"id":"CM-02","name":"Baseline Configuration","family":"CM","emphasis":"important"},{"id":"CM-03","name":"Configuration Change Control","family":"CM","emphasis":"important"},{"id":"CM-07","name":"Least Functionality","family":"CM","emphasis":"important"},{"id":"CM-08","name":"System Component Inventory","family":"CM","emphasis":"critical"},{"id":"IA-02","name":"Identification and Authentication (Organizational Users)","family":"IA","emphasis":"critical"},{"id":"IA-04","name":"Identifier Management","family":"IA","emphasis":"important"},{"id":"IA-05","name":"Authenticator Management","family":"IA","emphasis":"critical"},{"id":"IA-08","name":"Identification and Authentication (Non-organizational Users)","family":"IA","emphasis":"important"},{"id":"IA-09","name":"Service Identification and Authentication","family":"IA","emphasis":"critical"},{"id":"IR-04","name":"Incident Handling","family":"IR","emphasis":"important"},{"id":"IR-05","name":"Incident Monitoring","family":"IR","emphasis":"important"},{"id":"PL-08","name":"Security and Privacy Architectures","family":"PL","emphasis":"important"},{"id":"RA-03","name":"Risk Assessment","family":"RA","emphasis":"important"},{"id":"RA-05","name":"Vulnerability Monitoring and Scanning","family":"RA","emphasis":"important"},{"id":"SA-08","name":"Security and Privacy Engineering Principles","family":"SA","emphasis":"important"},{"id":"SA-11","name":"Developer Testing and Evaluation","family":"SA","emphasis":"important"},{"id":"SC-07","name":"Boundary Protection","family":"SC","emphasis":"critical"},{"id":"SC-08","name":"Transmission Confidentiality and Integrity","family":"SC","emphasis":"critical"},{"id":"SC-13","name":"Cryptographic Protection","family":"SC","emphasis":"important"},{"id":"SC-23","name":"Session Authenticity","family":"SC","emphasis":"important"},{"id":"SC-28","name":"Protection of Information at Rest","family":"SC","emphasis":"standard"},{"id":"SI-03","name":"Malicious Code Protection","family":"SI","emphasis":"standard"},{"id":"SI-04","name":"System Monitoring","family":"SI","emphasis":"critical"},{"id":"SI-10","name":"Information Input Validation","family":"SI","emphasis":"critical"},{"id":"SI-11","name":"Error Handling","family":"SI","emphasis":"important"},{"id":"SI-15","name":"Information Output Filtering","family":"SI","emphasis":"important"},{"id":"SR-02","name":"Supply Chain Risk Management Plan","family":"SR","emphasis":"standard"},{"id":"SR-03","name":"Supply Chain Controls and Processes","family":"SR","emphasis":"standard"}],"controlFamilySummary":{"AC":9,"AT":2,"AU":4,"CA":2,"CM":4,"IA":5,"IR":2,"PL":1,"RA":2,"SA":2,"SC":5,"SI":5,"SR":2}}}