
Browser Security Headers Pack — SAMPLE
SAMPLE Permissions-Policy / Referrer-Policy / XCTO / XFO header pack.
- File
- HEADERS · Headers
- Use case
- API testing
The security category is a first-class hub for auth and PKI SAMPLE fixtures, published sample-only material that must never be used as a real identity. It deepens certificate and key coverage under permanent /files/security/… paths (the older data/security paths remain shipped and unchanged). Expect self-signed X.509 certificates and CSRs, RSA/Ed25519 keys, PKCS#12 SAMPLE bundles, JWT algorithm variants (none/HS/RS), JWKS documents, OAuth token-response JSON, CORS and CSP header text, htpasswd variants, and SSH known_hosts samples. Every private key and token is labelled SAMPLE and deliberately committed for parser, TLS, and auth-harness tests.
Filter security on Browse · 135 files · 8 subcategories

SAMPLE Permissions-Policy / Referrer-Policy / XCTO / XFO header pack.

SAMPLE CSP header line for CSP parsers and security-header scanners.

Intentionally misconfigured CORS SAMPLE (* + credentials) for policy linters.

SAMPLE CORS response header block as plain text for header parsers and policy tests.

SAMPLE Strict-Transport-Security header for TLS policy scanners.

SAMPLE HTTP security header fixture (content-security-policy-report) for scanner regression.

SAMPLE HTTP security header fixture (cross-origin-embedder) for scanner regression.

SAMPLE HTTP security header fixture (cross-origin-opener) for scanner regression.

SAMPLE HTTP security header fixture (cross-origin-resource) for scanner regression.

SAMPLE HTTP security header fixture (expect-ct-legacy) for scanner regression.

SAMPLE HTTP security header fixture (permissions-policy) for scanner regression.

SAMPLE HTTP security header fixture (referrer-policy-strict) for scanner regression.

SAMPLE HTTP security header fixture (strict-transport-security) for scanner regression.

SAMPLE HTTP security header fixture (x-content-type-options) for scanner regression.

SAMPLE HTTP security header fixture (x-frame-options-deny) for scanner regression.

SAMPLE X-XSS-Protection: 0 header for legacy header scanners.

SAMPLE htpasswd using Apache APR1 MD5-style hash for legacy Basic-auth tests.

SAMPLE htpasswd with a bcrypt hash line for Basic-auth file parsers.

Multi-user SAMPLE htpasswd mixing bcrypt, APR1, and {SHA} lines for algorithm-detection tests.

Empty JWKS keys array for edge-case JWKS loaders.

SAMPLE JWKS document exposing the Wave G RSA public key for JWT signature verification tests.

A single P-256 public JWK. Its x and y are fixed 32-byte base64url values, left-padded when a coordinate happens to be short — the padding rule that libraries stripping leading zeroes get wrong.

An OKP-type JWK holding the Ed25519 key pair as raw 32-byte x and d values. OKP is the newest JWK key type and the one older JOSE libraries reject outright.

The full RSA private key as a JWK, including the CRT parameters p, q, dp, dq and qi. It is the input for testing JWK-to-PEM conversion, where dropping the CRT values quietly costs a large amount of signing performance.

The symmetric HMAC secret used by this wave's HS256 tokens, expressed as an oct JWK. The secret is printed in the specs on purpose so a verifier can be wired up without guessing.

Two keys of different types published under the same kid — what a botched key rotation leaves behind. A resolver that returns the first match silently verifies against the wrong key type instead of reporting the ambiguity.

A JWK Set whose keys carry no kid at all, which RFC 7517 permits. Verifiers must then fall back to trying candidates by algorithm, and the ones that index the set by kid alone find nothing.

A three-key JWK Set publishing the public halves of this wave's RSA, P-256, and Ed25519 keys, each with a distinct kid. It is the resolver input for every p7 JWT, so kid selection can be tested against a set that really has more than one candidate.

A JWK carrying the full x5c certificate chain and an x5t#S256 thumbprint alongside the raw n/e values. The x5c array is standard Base64 while every other JWK field is base64url — a real and frequently mis-implemented detail.

Intentionally invalid JWT (truncated) for parser error-path tests.

SAMPLE HS256 JWT with a past exp claim — for expiry-validation harnesses.

SAMPLE JWT with alg=HS256 for auth parsers and algorithm-handling tests. Published sample material only.

SAMPLE JWT with alg=HS384 for auth parsers and algorithm-handling tests. Published sample material only.

SAMPLE JWT with alg=HS512 for auth parsers and algorithm-handling tests. Published sample material only.

SAMPLE JWT with alg=none for auth parsers and algorithm-handling tests. Published sample material only.

SAMPLE JWT with alg=RS256 for auth parsers and algorithm-handling tests. Published sample material only.

SAMPLE JWT with alg=RS384 for auth parsers and algorithm-handling tests. Published sample material only.

SAMPLE JWT with alg=RS512 for auth parsers and algorithm-handling tests. Published sample material only.

JWT Header Claims — RS256 SAMPLE — unsigned JSON companion for claim-parser tests (not a live token).

JWT Payload — Expired SAMPLE — unsigned JSON companion for claim-parser tests (not a live token).

The single-signature flattened JSON form of the exact same RS256 token shipped in compact serialization. Both encodings must verify to the identical payload, which is the round-trip this pair is for.

One payload carrying two independent signatures — RS256 and EdDSA — in the General JSON serialization that the compact form cannot express. Multi-signature handling is the part of RFC 7515 most libraries never implemented.

An unsecured JWS: alg is none and the signature segment is empty, leaving only the trailing dot. Any verifier that accepts it will accept a claim set an attacker wrote, which is why this is the first negative test to run.

The classic algorithm-confusion shape: a token that claims HS256 while its kid points at an RSA key, MACed with that key's public PEM as the shared secret. A verifier that picks its algorithm from the header rather than from the key type accepts it.

The EdDSA token with one bit of its signature flipped. Ed25519 verification either succeeds or fails with no partial credit, which makes this the cleanest possible negative case.

An EdDSA (Ed25519) token with a fixed 64-byte signature and the same claim set as the RS256 reference. EdDSA signing is deterministic, so this token is reproducible in a way an ES256 one could never be.

A symmetric HS256 token whose secret is printed in the specs and shipped as an oct JWK, so a verifier can be stood up without any key exchange. It shares its claim set with the RS256 reference token.

The valid RS256 token with the last bit of its signature flipped. Header and payload are byte-identical to the valid twin, so any difference in outcome is entirely down to signature verification.

A correctly signed RS256 token whose exp passed on 2020-01-01. The signature still verifies, so it isolates expiry handling from every other check — including the libraries that validate the signature and then forget to look at exp.

A valid signature over a claim set whose nbf is 2035. Many verifiers check exp diligently and skip nbf entirely, so this is the token that finds out.

A perfectly well-formed RS256 signature made with the SAMPLE root key while the kid header still names the leaf key. Verifiers that trust the kid without checking the signature against that exact key accept it.

The reference token for this wave: RS256, signed by the SAMPLE leaf key, with iss, aud, iat, nbf, exp and jti all present and an expiry in 2036. Every other JWT here is a deliberate deviation from it.

A genuinely valid RS256 signature whose kid names a key that has been rotated out of the JWK set. The right behaviour is a clean key-not-found error, not a silent fallback to whichever key happens to be first.

SAMPLE OAuth device-authorization response for device-flow client tests.

OAuth 2.0 SAMPLE error JSON (insufficient_scope) for client error-path tests.

OAuth 2.0 SAMPLE error JSON (invalid_client) for client error-path tests.

OAuth 2.0 SAMPLE error JSON (invalid_grant) for client error-path tests.

OAuth 2.0 SAMPLE error JSON (invalid_scope) for client error-path tests.

OAuth 2.0 SAMPLE error JSON (temporarily_unavailable) for client error-path tests.

OAuth 2.0 SAMPLE error JSON (unauthorized_client) for client error-path tests.

SAMPLE OAuth error JSON for token-endpoint failure handling.

SAMPLE RFC 7662-style token introspection response for auth middleware tests.

SAMPLE OAuth 2.0 token endpoint JSON with access, refresh, and id_token fields.

SAMPLE OpenID Connect discovery document for OIDC client and metadata parsers.

ASCII-armored SAMPLE-shaped PGP public key placeholder for armor detectors (not a cryptographically valid key).

SAMPLE CRL metadata JSON (no binary CRL) for revocation-list UI and loader tests.

Deterministic SAMPLE Ed25519 private key for SSH/TLS tooling tests.

Password-encrypted SAMPLE PKCS#8 private key (password printed in specs) for decrypt-import tests.

PKCS#10 certificate signing request SAMPLE for CSR parsers and CA tooling smoke tests.

SAMPLE PKCS#12 keystore (password `novus-sample-wg`) for keystore importer tests. Not byte-stable.

Published SAMPLE RSA-2048 private key (PKCS#8 PEM). Never use for a real identity.

The two CA certificates concatenated in trust-store order, the shape a `--cafile` or `ca-bundle.crt` argument expects. Point a client at this and every other valid p7 leaf becomes verifiable.

A correctly signed CRL with an absent revokedCertificates field — what a CA publishes when it has revoked nothing. Parsers that assume the list is always present tend to fault here rather than report zero entries.

A validly signed CRL whose nextUpdate passed in 2020. Whether a client hard-fails, soft-fails, or silently trusts stale revocation data is a real policy decision, and this is the fixture that reveals which one it made.

Binary DER twin of the SAMPLE CRL — the exact encoding a CRL distribution point serves over HTTP. Use it to test binary CRL fetching and caching paths that never see PEM armour.

The issuing CA's revocation list, PEM-armoured, naming the revoked SAMPLE leaf (keyCompromise) plus a second serial with no matching certificate file — because a real CRL lists serials, not certificates. Signed by the same intermediate that issued them.

The bundle a TLS server actually presents: leaf first, then the issuing CA, with the root deliberately omitted because clients must already trust it. This is the correct-by-construction reference for the chain-order fixtures beside it.

The same chain with the self-signed root appended. Sending the root is legal and common, merely wasteful, so a verifier must ignore the extra anchor rather than treat it as an error.

Leaf plus root with the issuing CA left out — the single most common TLS misconfiguration, and the one that works in browsers with a cached intermediate and fails everywhere else. Use it to prove a client does not silently paper over the gap.

The leaf and intermediate concatenated backwards. Strict servers reject the file outright while tolerant path builders reorder it silently, so it cleanly separates the two behaviours.

A mutual-TLS client certificate: EC P-256 subject key, clientAuth EKU only, and an OU naming the fictional access group. Present it to an mTLS endpoint to test client-certificate parsing and EKU enforcement.

A code-signing certificate (codeSigning EKU, digitalSignature only) issued by the SAMPLE intermediate. It signs nothing real — it exists so signature-verification tooling has an EKU-correct certificate to reason about.

A CSR with nothing but a Common Name and no requested extensions — the output of the shortest possible openssl req invocation. Intake code that assumes an extensionRequest attribute exists breaks on it.

An Ed25519 certificate request. Its signature algorithm identifier carries no separate hash OID, which is exactly the field that trips older CSR parsers written around RSA and ECDSA.

An intentionally corrupt PKCS#10 request: the PEM armour is intact but four illegal characters have been substituted into the Base64 body, so decoding fails part-way. It exists to check that a CSR intake path reports a parse error instead of a stack trace or a partially populated record.

The CSR shape a modern CA expects: full subject DN, a requested subjectAltName extension, and a self-signature proving possession of the RSA key. Everything a CA intake form needs to parse.

A wildcard certificate request covering *.csr.pki.sample.example plus the apex. CA policy engines usually treat wildcards specially, so this is the input that exercises that branch.

The exact bytes covered by the detached PKCS#7 signature shipped beside it. LF line endings are part of the contract — rewriting the file with CRLF is the fastest way to watch a signature check fail for a reason nobody suspects.

The P-256 key behind the EC leaf certificate, in PKCS#8. Its scalar is derived deterministically from a fixed label so the whole wave reproduces byte for byte.

The same P-256 scalar in the SEC 1 container (BEGIN EC PRIVATE KEY), which names the curve inline instead of through a PKCS#8 algorithm identifier. Some deployment tools accept only one of the two.

The P-256 public key in SubjectPublicKeyInfo form, carrying the named-curve OID and an uncompressed point. It matches the EC leaf certificate and the EC entry in the p7 JWK set.

The Ed25519 key behind the Ed25519 leaf and the EdDSA JWTs, in PKCS#8. RFC 8410 keys have no traditional-OpenSSL container at all, which is why only one serialisation ships.

Binary DER encoding of the SAMPLE intermediate CA certificate — the same bytes the PEM twin Base64-wraps. Feed it to ASN.1 decoders, Java keystores, and DER-to-PEM converters.

The issuing CA that signs every leaf in this wave, itself signed by the SAMPLE root and constrained with pathLenConstraint:0 so it cannot mint further CAs. Use it to test intermediate handling and path-length enforcement.

The elliptic-curve twin of the reference leaf: identical subject, SANs, EKU and issuer, but a P-256 subject public key instead of RSA-2048. Diff the two to isolate exactly what changes when a deployment migrates key types.

The third key-type variant of the reference leaf, carrying an Ed25519 subject public key. Older TLS stacks and keystores reject id-Ed25519 outright, which makes this a compact compatibility probe.

A correctly signed leaf whose notAfter fell in the past (2020). The only thing wrong with it is the clock, which makes it the clean way to assert that an expiry error is reported as expiry and not as a signature failure.

A leaf whose SAN carries both a DNS name and an iPAddress entry (192.0.2.10, from the RFC 5737 documentation range). Connecting by literal IP must match the iPAddress entry, never the DNS one.

A pre-RFC 6125-style certificate carrying only a Common Name and no subjectAltName extension. Every current browser and most TLS libraries reject it outright, which makes it a precise legacy-compatibility probe.

The mirror of the expired leaf: identical in every respect except that notBefore is 2035, so it is rejected from the other side of the validity window. Pairs with it to prove a verifier distinguishes the two clock errors.

A leaf that is valid in every structural respect and revoked in the matching CRL and OCSP response shipped alongside it. It is the fixture that proves a client actually performs revocation checking rather than stopping at path building.

The reference end-entity certificate for this wave: RSA-2048 subject key, two DNS SANs, serverAuth/clientAuth EKU, and AIA/CRL pointers to the fictional SAMPLE responder. Everything else in the p7 PKI is a deviation from this one.

The certificate's CN is app.pki.sample.example but its only SAN is different.pki.sample.example. RFC 6125 clients must ignore the CN entirely, so this separates modern verifiers from ones still falling back to Common Name.

An end-entity certificate that signs itself and chains to nothing — the shape a development server produces when nobody ran a CA. It is internally consistent, so the only defect a verifier can find is the missing trust anchor.

A wildcard certificate covering *.wild.pki.sample.example plus the bare apex. Use it to check that a matcher accepts exactly one label and refuses to stretch the wildcard across a dot.

A valid, correctly chained certificate for the wrong host: both CN and SAN say wrong-host.pki.sample.example. Serve it for leaf.pki.sample.example to exercise the hostname-verification path on its own.

Binary DER encoding of the SAMPLE leaf certificate — the same bytes the PEM twin Base64-wraps. Feed it to ASN.1 decoders, Java keystores, and DER-to-PEM converters.

The DER OCSPRequest a client sends when checking the reference leaf, with the SHA-1 CertID that RFC 6960 mandates and no nonce extension. POST it at a stub responder to exercise request parsing without a live CA.

A successful OCSP response asserting status good for the reference leaf, signed directly by the SAMPLE issuing CA. Pair it with the request beside it to stub a responder end to end.

The OCSP counterpart of the CRL entry: status revoked for the revoked SAMPLE leaf, with the same 2026-03-01 revocation time and keyCompromise reason. Use both against the same certificate to check that CRL and OCSP paths agree.

The minimal unsuccessful OCSP response: responseStatus unauthorized and no responseBytes at all, which is what a responder returns for a certificate it does not serve. A handful of bytes that regularly breaks clients expecting a signed body.

A password-protected PKCS#12 keystore holding the SAMPLE leaf key together with its whole issuing chain, so one import gives a client both an identity and its anchors. The password `novus-p7-sample-p12` is published on purpose; nothing inside is a real credential.

The same leaf key and certificate in a PKCS#12 file with no password and no encryption. Several importers refuse an empty password, prompt anyway, or treat it as the literal empty string, so this is the fixture that finds out which.

Binary DER form of the same three-certificate PKCS#7 bundle, the encoding a .p7b download actually uses. Use it to test importers that never see the PEM armour.

A degenerate (certificates-only) PKCS#7 structure holding all three SAMPLE certificates under BEGIN PKCS7 armour — the payload Windows and Java tools distribute as a .p7b. It carries no private key and no signature over any content.

A detached PKCS#7 SignedData over signed-payload.txt, built without signed attributes so the bytes are reproducible. The content is not embedded, so verification needs both files — exactly the failure mode people hit with .p7s email attachments.

Binary DER encoding of the SAMPLE root CA certificate — the same bytes the PEM twin Base64-wraps. Feed it to ASN.1 decoders, Java keystores, and DER-to-PEM converters.

The self-signed root of the Novus Examples SAMPLE certificate hierarchy (RSA-4096, CA:TRUE, no path-length limit). Install it as the only trust anchor to make the rest of this wave's chains verifiable in a sandbox. Fictional issuer — never a real identity.

The legacy encrypted-key layout: PKCS#1 body plus `Proc-Type: 4,ENCRYPTED` and `DEK-Info` PEM headers carrying the cipher and IV, password `novus-p7-sample-pkcs1`. Parsers that strip PEM headers before decoding silently lose the IV and fail here.

The identical key material wrapped in the legacy PKCS#1 container (BEGIN RSA PRIVATE KEY), which omits the algorithm OID that PKCS#8 carries. Diff it against its PKCS#8 twin to see exactly what a container migration changes.

The SAMPLE leaf key under PKCS#8 password encryption (BEGIN ENCRYPTED PRIVATE KEY, PBES2), password `novus-p7-sample-pkcs8`. Encryption metadata lives inside the ASN.1 here, not in PEM headers — the opposite of the PKCS#1 twin.

The SAMPLE leaf's RSA-2048 key in unencrypted PKCS#8 (BEGIN PRIVATE KEY) — the modern default and the pair to the PKCS#1 twin beside it. It is deliberately published; treat it as public.

The same modulus and exponent in the raw PKCS#1 RSAPublicKey container, without the algorithm-identifier wrapper. Libraries routinely accept one armour and reject the other, so the pair is the test.

The SAMPLE leaf's public key as a bare SubjectPublicKeyInfo (BEGIN PUBLIC KEY) — the form JWT verifiers and most language runtimes expect when you hand them a key rather than a certificate.

An S/MIME-shaped certificate whose SAN is an rfc822Name rather than a DNS name, with the emailProtection EKU and a non-repudiation key usage. Useful for testing address extraction from certificates.

Same SAMPLE certificate as .crt (PEM bytes) for tools that expect the CRT extension.

DER-encoded twin of the Wave G SAMPLE certificate for binary X.509 decoders.

Self-signed X.509 SAMPLE certificate in PEM under /files/security/ — published sample material for TLS and PEM parsers.

Two-PEM-block SAMPLE chain file for multi-cert parsers and bundle importers.

The P-256 public key in OpenSSH form, whose blob names the curve twice — once in the key type and once inside the payload. Parsers that read only one of the two mis-handle mismatched keys.

The SAMPLE leaf's RSA key in single-line OpenSSH format with a comment — the same key material as the PEM public keys, wrapped the way authorized_keys wants it. Handy for checking that a fingerprint tool agrees across encodings.

Single-entry SAMPLE authorized_keys file for SSH access-control parsers.

SAMPLE OpenSSH client config stanza for SSH config parsers.

OpenSSH-format SAMPLE Ed25519 public key for authorized_keys and SSH parsers.

SAMPLE SSH known_hosts with fictional hostnames for known_hosts parsers and StrictHostKeyChecking tests.
Never. Every key, cert, JWT, and token is published SAMPLE-only material under /files/security/…, do not use them as real identities. Older data/security paths remain shipped and unchanged.
SAMPLE JWTs for none, HS256/384/512, and RS256/384/512, plus expired and intentionally invalid tokens, JWKS, and OAuth token-response JSON.
Yes, plain-text header fixtures for CORS, CSP, HSTS, and a deliberately misconfigured CORS sample for policy linters.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.