SAML replay detection implementation
Implement proper replay detection either at the response or assertion level in IdP-initiated SSO flows. This counters replay attacks.
OWASP Cheat Sheets · all subjects
application_security/headers
104 notes in this subject, read out of this brain and free to use. This is page 2 of 2.
RSA 2048 and SHA-256 as SAML certificate standard
The most supported and currently secure combination for SAML certificates is using RSA 2048 bit keys and SHA-256 hashing/signing. This refers to the certificate's signing algorithm, not the SAML XML signing algorithm.
ECC keys for SAML certificates
ECC keys can be much smaller while providing more security than RSA keys and the math involved is faster to perform. These are preferred when all parties can use them. ECC keys can be as low as 256 bit and still be secure. However, at least one major vendor (Microsoft Entra) does not support ECC keys.
Minimum RSA key size for SAML certificates
The minimum RSA key size for SAML certificates should be 2048 bit.
SHA-1 prohibited for SAML certificate signing
No IdP should use SHA-1 as the certificate signing hash. SHA-256 is the minimum bar. If possible, moving to larger hash algorithms like SHA-384 or SHA-512 means better future-proofing the service.
SAML signing certificate maximum lifetime
The maximum lifetime of a SAML signing certificate should be two years. NIST SP 800-57 allows RSA 2048 bit keys to last three years, but two years is the recommended maximum for SAML. If the private key is not well protected, such as in a Hardware Security Module, that may be too long to be safe.
Extended Key Usage (EKU) id-kp-documentSigning for SAML
EKU describes a specific use case the certificate is intended for. There is no widely accepted EKU for SAML signing, but RFC 9336 defines id-kp-documentSigning (OID 1.3.6.1.5.5.7.3.36) which is ideal for this purpose. IdPs and SPs may consider standardizing on this EKU.
Key Usage (KU) requirements for SAML certificates
Key Usage describes the underlying cryptographic operations the private key is meant for, such as digitalSignature, nonRepudiation, and keyEncipherment. IdPs and SPs should require digitalSignature and disallow certificates that have other KUs, as certificates should only be used for one use case. For example, the IdP's TLS server certificate must never be the SAML signing certificate.
CRL Distribution Point validation for SAML certificates
If a SAML certificate has a CRL Distribution Point listed, it should be reachable by the validating party and the party should validate it according to RFC 5280 section 6.3. Parties in a SAML system should establish a plan with contact lists to notify and rotate certificates rapidly in case of a compromised private key.
OCSP for SAML certificate revocation checking
OCSP (Online Certificate Status Protocol) is a way of checking if a certificate is revoked. The OCSP URL is embedded in the certificate and should be reachable over HTTP. The response is signed, so MITM attacks are not an integrity concern. If an OCSP URL is present on any certificate in the chain, it should be used to check if the certificate is revoked.
Self-signed SAML certificates as preferred option
Self-signed SAML certificates are the clear winner when proper precautions are taken for exchanging the certificates. They allow for certificate and lifetime configurations not constrained by public or private CA policies, and can be set with the longest safely possible lifetime, which is important since rotating SAML certificates is painful and labor intensive.
Public CA signed SAML certificate limitations
Public CA signed certificates require each SP to simultaneously update its explicit trust when the IdP rotates its SAML signing certificate, which is challenging with many SPs. Recent changes in certificate lifetimes make them less appealing. The CA Browser Forum is moving toward 47-day certificate lifetimes, meaning IdPs and SPs would be in perpetual certificate update cycles.
Private CA audit requirements for SAML
If relying on third-party CAs for SAML certificates, they should be WebTrust, ETSI, or SOC 2 Type II audited. If third-party CAs are used, ensure they are only trusted for the process of IdP signature validation and not for other purposes such as TLS or code signing.
Self-signed SAML certificate generation with openssl
To generate a self-signed SAML certificate using openssl: 1. Generate a Private Key: openssl genrsa -out private.key 2048 or openssl ecparam -genkey -name prime256v1 -out private.pem 2. Create a Configuration File (cert.cnf): [req] distinguished_name = req_distinguished_name x509_extensions = v3_ca prompt = no [req_distinguished_name] C = US ST = California L = San Francisco O = MyOrganization OU = MyUnit CN = SAML Signing [v3_ca] basicConstraints = CA:FALSE keyUsage = digitalSignature extendedKeyUsage = 1.3.6.1.5.5.7.3.36 3. Generate the Self-Signed Certificate: openssl req -x509 -new -nodes -key private.key -sha256 -days 365 -out certificate.crt -config cert.cnf -extensions v3_ca
SAML metadata URL certificate exchange
Many IdPs publish a metadata URL that contains basic configuration information including the SAML signing certificate. Many SPs can consume data from the IdP metadata URL, updating the signing certificate information in near real-time. This model matches the intent of certificate and public key pinning. The metadata URL should be protected using TLS with a server certificate from a WebPKI CA that is widely trusted.
Hardware Security Module (HSM) for SAML signing keys
SAML signing keys are a top security asset and target of attackers. IdP operators should strongly consider protecting the private keys using a Hardware Security Module (HSM). HSMs allow an application to use a key without it being exportable or copyable. They have mechanisms to safely replicate keys into failover HSMs without exposing the keys outside of the HSMs. Quality HSMs should be rated FIPS 140-2 or FIPS 140-3.
SP signature algorithm minimum requirement
Service Providers must explicitly verify the signature algorithm is at least RSA-SHA-256 or stronger. Reject SHA-1-based algorithms including http://www.w3.org/2000/09/xmldsig#rsa-sha1, ...#hmac-sha1 and <ds:DigestMethod Algorithm="...sha1">. NIST SP 800-131A Rev. 2 disallows SHA-1 in digital signatures.
SP IdP certificate revocation validation
Service Providers must validate IdP certificates for revocation against CRL/OCSP if they are present.
SAML assertion exchange over TLS
Exchange SAML assertions only over secure transports like TLS.
Web Application Firewall deployment location and purpose
Web Application Firewalls (WAF) monitor or block common attack payloads like XSS and SQLi, or allow only specific request types and patterns. Applications should attach WAFs to entry points like load balancers or API gateways as a first line of defense to handle potentially malicious content before it reaches application code.
Cloud provider managed WAF rule sets
Cloud service providers curate base rule sets for WAF: AWS Managed Rules (https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-list.html), GCP WAF Rules (https://cloud.google.com/armor/docs/waf-rules), Azure Core Rule Sets (https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-crs-rulegroups-rules?tabs=owasp32). These rule sets are generic and do not cover every attack type an application will face, so consider creating custom rules for specific security needs.
Custom WAF rules for application-specific needs
Create custom WAF rules for application-specific security needs: filtering routes to acceptable endpoints to block web scraping, adding specific protections for chosen technologies and key application endpoints, and rate limiting sensitive APIs.
CORS configuration with nelmio/cors-bundle
Install nelmio/cors-bundle to manage CORS policies in Symfony: 'composer require nelmio/cors-bundle'. Configuration is done in config/packages/nelmio_cors.yaml.
CORS bundle default configuration structure
nelmio_cors configuration in YAML includes: 'defaults' section with origin_regex, allow_origin, allow_methods, allow_headers, expose_headers, max_age settings; and 'paths' section for route-specific overrides. The '~' symbol in paths means configuration is inherited from defaults.
Security headers recommended for Symfony applications
Essential security headers to add to responses: Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Content-Security-Policy, X-Permitted-Cross-Domain-Policies, Referrer-Policy, Clear-Site-Data, Cross-Origin-Embedder-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, Cache-Control.
Adding security headers in Symfony response
Add security headers to responses by setting them on the Response object. Example: $response = new Response(); $response->headers->set('X-Frame-Options', 'SAMEORIGIN');
Adding security headers via ResponseEvent listener
Security headers can be added automatically by listening to the ResponseEvent to apply headers to every response in the application.
Azure App Service domain verification via TXT records
Azure App Service supports custom domain verification via TXT records. Adding a verification TXT record (e.g., `asuid.subdomain TXT <verification-id>`) ties the custom domain to a specific Azure subscription. Keep this TXT record in place even after decommissioning the App Service to prevent another tenant from claiming the domain.
Google Cloud domain verification through Search Console or DNS TXT records
Many GCP services require domain verification through Google Search Console or a DNS TXT record before a custom domain can be associated. Retain verification records as long as the DNS record exists to prevent other tenants from claiming the domain.
Cloudflare custom hostname verification for SaaS
Cloudflare for SaaS configurations should use the custom hostname verification feature to prevent hostname claim conflicts. Documentation is available at https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/.
Content Security Policy configuration to prevent subdomain takeover bypass
Avoid using `*.example.com` in CSP directives. Explicitly list trusted subdomains instead. A taken-over subdomain matching a CSP wildcard allows the attacker to inject scripts or exfiltrate data without violating the policy.
CORS configuration to prevent subdomain takeover bypass
Do not use wildcard subdomain patterns in `Access-Control-Allow-Origin` validation. Validate against an explicit allowlist of trusted origins to prevent a taken-over subdomain from bypassing CORS protections.
HSTS header requirement for privacy protection
HTTP Strict Transport Security (HSTS) is an HTTP header set by the server indicating to the user agent that only secure (HTTPS) connections are accepted. HSTS prompts the user agent to change all insecure HTTP links to HTTPS and forces compliant user agents to fail-safe by refusing any TLS/SSL connection that is not trusted by the user. Developers should enable HSTS for all users, or at minimum give users the choice to enable it.
HTTP Strict Transport Security implementation
HTTP Strict Transport Security (HSTS) instructs the user's browser to always request the site over HTTPS and prevents the user from bypassing certificate warnings. See the HTTP Strict Transport Security Cheat Sheet for further implementation details.
Web service output encoding requirements
All the rules of output encoding apply as per the Cross Site Scripting Prevention Cheat Sheet. Web services need to ensure that the output sent to clients is encoded to be consumed as data and not as scripts, which is especially important when web service clients use the output to render HTML pages either directly or indirectly using AJAX objects.
TLS Cipher String Cheat Sheet deprecated
The TLS Cipher String Cheat Sheet has been deprecated. Users should instead consult the Transport Layer Security Cheat Sheet for current cipher guidance.
gRPC TLS configuration in Go
In Go, configure TLS for a secure gRPC server using credentials.NewServerTLSFromFile() with certificate and key file paths. Pass the credentials to grpc.NewServer() using grpc.Creds(creds). Configure TLS 1.2 or higher with strong cipher suites and disable weak protocols and ciphers.
Application security: Web Application Firewalls (WAFs)
Block OWASP Top 10 attacks at the application layer. Deploy at network edge, internal segments, or as part of API gateways.
Framing protection with CSP frame-ancestors
To prevent embedding of your application in iframes from other origins, use the Content Security Policy frame-ancestors directive. The syntax is in the CSP header. This blocks ability to embed your application in frames on attacker-controlled origins and protects against related attacks like Clickjacking.
Framing protection with X-Frame-Options header
X-Frame-Options header prevents embedding of your application in iframes from other origins. Use this primarily for supporting older browsers that may not support Content Security Policy frame-ancestors directive.
Sec-Fetch-Site header values for origin detection
The Sec-Fetch-Site header is automatically appended by the browser to each request as part of the Fetch Metadata standard. It specifies where the request was sent from and takes the following values: cross-site, same-origin, same-site, or none (user directly reached the page). Use this to build isolation policies, for example returning a 403 status for cross-site requests to sensitive APIs.
Cross-Origin-Resource-Policy (CORP) header values
The Cross-Origin-Resource-Policy (CORP) header controls whether resources from your site can be loaded by other origins. Possible values: same-site (resource can only be loaded by same-site origins), same-origin (resource can only be loaded by same-origin requests), cross-origin (resource can be loaded by any origin). When the server returns this header, the browser will not load resources from your site in another application, even static images.
Cache-Control header to disable caching
To disable caching for sensitive resources, set the response header Cache-Control: no-store. This prevents resources from being cached by the browser, eliminating cache timing XS Leak attacks. The trade-off is degraded performance due to requiring resources to be reloaded from the server every time.
Cross-Origin-Opener-Policy (COOP) header configuration
The Cross-Origin-Opener-Policy (COOP) response header ensures a top-level document does not share a browsing context group with cross-origin documents. This prevents cross-origin documents from opening in the same browsing context group, ensuring that document A opening another document will not have access to the window object. This protects against attacks like Spectre that can cross the security boundary of Same Origin Policy (SOP) for resources in the same browsing context group. Possible COOP values are: unsafe-none, same-origin-allow-popups, and same-origin. The recommended value is same-origin to isolate the browsing context exclusively to same-origin documents. When the server returns 'same-origin', attempting to access window.frames.length from a cross-origin popup returns null, defeating frame counting attacks. COOP works together with Cross-Origin-Embedder-Policy (COEP) and Cross-Origin-Resource-Policy (CORP). This header may not apply to REST APIs or non-browser clients.