FAQ-000046 - API Security Headers / Machine-to-Machine API Security

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
How should machine-to-machine API endpoints be configured to meet security review requirements, and why are security headers required even for APIs that don't serve HTML content?
Answer
Machine-to-machine API endpoints must meet security review requirements by: **Configuration Requirements:** 1. Ensuring secure transfer of credentials and data using TLS v1.2 or above. 2. Avoiding weak ciphers, such as export or NULL ciphers. 3. Marking session IDs as SECURE. 4. Prohibiting wildcarded CORS or cross-domain.xml files for non-public endpoints. 5. Testing endpoints with automated security scanning tools and addressing any vulnerabilities. If the endpoints are not controlled by the partner, exceptions may be granted with an action plan. **Security Header Requirements:** To address security header requirements for machine-to-machine API communications: 1. Securely store and transmit credentials. 2. Encrypt secrets using AES-128 or higher for server applications. 3. Store encryption keys so that the database process cannot directly access them (only the application layer should have access). 4. Avoid writing sensitive data, like API tokens or cryptographic keys, to logs or storing them in unencrypted form. 5. Use vendor-provided libraries for encryption instead of creating custom ones. **Why Security Headers Are Required:** Security headers are required for an API endpoint, even if it does not serve HTML content, to protect data and mitigate vulnerabilities. These headers help prevent attacks like cross-site scripting (XSS), clickjacking, and code injection by enforcing secure communication and restricting how content is handled by the client. They also ensure compliance with security best practices and standards. **Arguing False Positives:** To argue that missing security headers on a machine-to-machine API endpoint is a false positive: 1. Provide evidence that the endpoint is not accessed by browsers or user agents that rely on these headers for security. 2. Explain that the API is designed for server-to-server communication, where such headers are not applicable or necessary. 3. Document the security measures in place, such as mutual TLS, IP whitelisting, or other authentication mechanisms, to show that the endpoint is adequately secured. Include this reasoning in a false positive document for submission.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexInsecureEndpointAvoidInsecureHttpRemoteSiteSettingAvoidDisableProtocolSecurityRemoteSiteSettingApexBadCryptoApexSuggestUsingNamedCredAvoidHardcodedCredentialsInHttpHeaderAvoidHardcodedCredentialsInVarDeclsAvoidHardcodedCredentialsInFieldDecls
Question
How should machine-to-machine API endpoints be configured to meet security review requirements, and why are security headers required even for APIs that don't serve HTML content?
Recommended Answer Update
Machine-to-machine API endpoints must meet security review requirements by: **Configuration Requirements:** 1. Ensuring secure transfer of credentials and data using TLS v1.2 or above. 2. Avoiding weak ciphers, such as export or NULL ciphers. 3. Marking session IDs as SECURE. 4. Prohibiting wildcarded CORS or cross-domain.xml files for non-public endpoints. 5. Testing endpoints with automated security scanning tools and addressing any vulnerabilities. If the endpoints aren't controlled by the partner, exceptions may be granted with an action plan. **Security Header Requirements:** To address security header requirements for machine-to-machine API communications: 1. Securely store and transmit credentials. 2. Encrypt secrets using AES-128 or higher for server applications. 3. Store encryption keys so that the database process cannot directly access them (only the application layer should have access). 4. Avoid writing sensitive data, like API tokens or cryptographic keys, to logs or storing them in unencrypted form. 5. Use vendor-provided libraries for encryption instead of creating custom ones. **Why Security Headers Are Required:** Security headers are required for API endpoints, even if they don't serve HTML content, to protect data and mitigate vulnerabilities. These headers help prevent attacks like cross-site scripting (XSS), clickjacking, and code injection by enforcing secure communication and restricting how content is handled by the client. They also ensure compliance with security best practices and standards. **Arguing False Positives:** To argue that missing security headers on a machine-to-machine API endpoint is a false positive: 1. Provide evidence that the endpoint isn't accessed by browsers or user agents that rely on these headers for security. 2. Explain that the API is designed for server-to-server communication, where such headers aren't applicable or necessary. 3. Document the security measures in place, such as mutual TLS, IP whitelisting, or other authentication mechanisms, to show that the endpoint is adequately secured. Include this reasoning in a false positive document for submission.
Reasoning
The FAQ content is generally accurate and comprehensive. I made minor grammatical improvements to enhance readability: 'are not' → 'aren't', 'is not' → 'isn't', and 'do not' → 'don't' to follow the conversational tone guidelines without changing any technical content or structure. Regarding security rules selection: - ApexInsecureEndpoint: Directly relates to the FAQ's discussion of API endpoint security configuration requirements and testing for vulnerabilities - AvoidInsecureHttpRemoteSiteSetting and AvoidDisableProtocolSecurityRemoteSiteSetting: Connect to the TLS v1.2+ requirement and secure transfer protocols mentioned in configuration requirements - ApexBadCrypto: Relates to the encryption requirements (AES-128 or higher) and avoiding weak ciphers discussed in the security header section - ApexSuggestUsingNamedCred: Connects to secure credential storage and transmission practices covered in the security requirements - AvoidHardcodedCredentialsInHttpHeader, AvoidHardcodedCredentialsInVarDecls, AvoidHardcodedCredentialsInFieldDecls: All relate to the FAQ's emphasis on securely storing credentials and avoiding sensitive data in logs or unencrypted form
Reasoning References