Scope. This is a specification explainer with measurements from public data. We read the CVE Record Format schema on the CVEProject/cve-schema main branch (default dataVersion 5.2.0), RFD 0002 in the same repository, and the Package URL specification in the package-url/purl-spec repository. We counted fields across every record in the cvelistV5 release cve_2026-11-05_0400Z (the “all CVEs at midnight” bundle for 5 November 2026) with Python 3.13, and ran the join script below against that data. The script is illustrative.

The short answer

Since CVE Record Format 5.2.0, each entry in a record’s affected array can carry a packageURL:

{
  "vendor": "fast-uri",
  "product": "fast-uri",
  "packageURL": "pkg:npm/fast-uri",
  "defaultStatus": "unaffected",
  "versions": [
    {"versionType": "semver", "status": "affected", "version": "2.4.2", "lessThan": "2.4.8"}
  ]
}

That fragment is from CVE-2026-110180 (trimmed to its first version range). Three rules decide how you use it:

1. No version in the purl. The schema says the Package URL “MUST NOT include a version”. Strip the version from your SBOM purl before you look it up.
2. The versions array still decides. A purl match finds the records about your package. Whether your version is affected comes from versions and defaultStatus, read with the record’s versionType.
3. It is optional and still rare. 1.6% of published records carry it today, from 12 CNAs. Treat it as a fast, precise path where it exists, and keep your CPE and name-based matching for the rest.

What the schema says

The field definition in the 5.2.0 schema:

“A Package URL, a unified URL specification for identifying packages hosted by known package hosts. The Package URL MUST NOT include a version.”

The schema types it as a URI and lists examples such as pkg:deb/debian/curl?arch=i386&distro=jessie, pkg:npm/%40angular/animation and pkg:golang/google.golang.org/genproto#googleapis/api/annotations. So qualifiers and subpaths are allowed; only the version is out.

packageURL does not satisfy the identifier requirement on its own. The product definition still requires either vendor and product or collectionURL and packageName, plus either versions or defaultStatus. In our scan, every one of the 7,324 entries with a purl also had one of those identifier pairs.

Why it was added

RFD 0002, “Supporting Package URLs in CVE”, is the design record. It argues that the existing identifier fields “are of limited value for automated applicability matching” and that Package URLs “are better suited than CPEs for capturing distinctions between different distributions of particular open source software”.

Two design choices in the RFD matter to consumers:

• Validation is mostly outside the schema. The JSON schema only checks that the value is a URI; the RFD says it “would be further constrained by CVE Services” to ensure the values are valid purls, because encoding purl rules in a regular expression “would be excessive and difficult to maintain”. Do not assume the schema has validated purl syntax for you.
• Versions live in one place. “All version information should only be included within the existing versions field.” That keeps one version-matching code path for consumers.

The cve-schema repository tags v5.2.0; the tagged commit is dated 3 September 2025. Records that declare dataVersion 5.1 cannot use the field. In our snapshot, 144,619 published records (36.1%) declared 5.2 and 255,826 declared 5.1.

What the data shows

We read every record in the 5 November 2026 bundle: 400,445 published and 18,890 rejected. Only CNA containers carried the field; no ADP container had a packageURL.

Who writes it

VulnCheck accounts for 78.8% of records with a purl. If you build matching around this field, most of your hits will come from one CNA’s conventions, so test against its records.

Which purl types

The most common types across the 7,324 entries: github 2,371, npm 1,729, pypi 805, maven 533, golang 498, composer 314, hex 309, cargo 242, cpan 210, otp 82, software-id 72, nuget 40, gem 31, generic 31.

Two of those need care:

• pkg:github identifies a source repository, not a registry package. VulnCheck wrote 1,917 of the GitHub entries and EEF 413. Your SBOM will usually describe the same software as pkg:npm/... or pkg:pypi/..., so a pkg:github record will not match it directly. You need a mapping from repository to registry package, or a fallback on collectionURL and packageName.
• pkg:software-id appears 72 times (for example pkg:software-id/erlang.org/otp), but the purl-spec decision record that registers it, dated 21 October 2026, still has the status “proposed”. Expect parsers to reject it until the type is registered.

How fast it is growing

By the month each record was first published (as the records stand today, so later updates are included):

October’s 2,000 are 11.7% of the 17,058 records first published that month.

Normalize before you join

The purl specification makes the type case-insensitive with lowercase as the canonical form, and some types go further. The type definitions say a GitHub namespace and name are “not case sensitive and shall be lowercased”, and a PyPI name “shall be lowercased and underscore _ replaced with a dash -”. npm names are case-sensitive.

CVE records do not always follow those rules:

• 756 of the 2,371 pkg:github entries (31.9%) contain uppercase letters, for example pkg:github/Finsys/dockhand.
• 9 pkg:pypi entries have uppercase letters and 24 contain an underscore.
• GitPython is a concrete case. In the 34 records we found for it, 28 use pkg:pypi/gitpython and 6 use pkg:pypi/GitPython. An exact string join misses one set or the other, depending on how your SBOM tool spells it.

So normalize both sides the same way before comparing: lowercase the type; lowercase github and pypi paths; replace _ with - for pypi; drop the version and qualifiers from the SBOM purl. Leave npm, Maven and other case-sensitive types alone.

A tested join

Two scripts. The first builds an index from the cvelistV5 bundle; the second joins a CycloneDX SBOM to it and applies the versions ranges.

#!/usr/bin/env python3
"""build_index.py: index CNA affected[] entries that carry packageURL,
keyed by a normalized purl (no version, no qualifiers)."""
import json, sys, zipfile

def norm(purl):
    core = purl.split("#")[0].split("?")[0]
    if "@" in core.rsplit("/", 1)[-1]:                 # drop a version (SBOM side)
        core = core.rsplit("@", 1)[0]
    scheme, rest = core.split(":", 1)
    ptype, _, path = rest.partition("/")
    ptype = ptype.lower()
    if ptype in ("github", "pypi"):                     # case-insensitive types per purl-spec
        path = path.lower()
    if ptype == "pypi":
        path = path.replace("_", "-")
    return f"pkg:{ptype}/{path}"

def main(zip_path, out_path):
    z = zipfile.ZipFile(zip_path)
    with open(out_path, "w") as out:
        for n in z.namelist():
            if not n.endswith(".json") or "/CVE-" not in n:
                continue
            rec = json.loads(z.read(n))
            meta = rec["cveMetadata"]
            if meta.get("state") != "PUBLISHED":
                continue
            for a in rec["containers"].get("cna", {}).get("affected", []):
                if a.get("packageURL"):
                    out.write(json.dumps({"key": norm(a["packageURL"]), "cve": meta["cveId"],
                        "defaultStatus": a.get("defaultStatus"), "versions": a.get("versions", [])}) + "\n")

if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2])

#!/usr/bin/env python3
"""join_sbom.py: join CycloneDX component purls to the CVE packageURL index, then apply versions[] ranges.
Illustrative: only semver-like versionType values are compared; everything else is flagged for review."""
import json, sys
from packaging.version import Version, InvalidVersion
from build_index import norm

def status_for(ver, entry):
    try:
        v = Version(ver)
    except InvalidVersion:
        return "review: unparseable version"
    for r in entry["versions"]:
        if r.get("versionType") not in ("semver", "maven", "python", None):
            return f"review: versionType={r.get('versionType')}"
        try:
            lo = Version(r["version"]) if r["version"] not in ("0", "*") else Version("0")
            if "lessThan" in r:
                inside = lo <= v < Version(r["lessThan"])
            elif "lessThanOrEqual" in r:
                inside = lo <= v <= Version(r["lessThanOrEqual"])
            else:
                inside = v == lo
        except InvalidVersion:
            return "review: unparseable range"
        if inside:
            return r["status"]
    return entry.get("defaultStatus") or "unknown"

def main(index_path, sbom_path):
    index = {}
    for line in open(index_path):
        e = json.loads(line)
        index.setdefault(e["key"], []).append(e)
    for c in json.load(open(sbom_path))["components"]:
        for e in index.get(norm(c["purl"]), []):
            print(f'{c["purl"]}\t{e["cve"]}\t{status_for(c["version"], e)}')

if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2])

Test run

python3 build_index.py cves.zip purl-index.jsonl took about 30 seconds and wrote 7,324 lines, one per entry. We then ran python3 join_sbom.py purl-index.jsonl sbom.cdx.json (packaging 26.3) with a three-component CycloneDX 1.6 SBOM:

GitPython 3.1.62 comes out affected by the six records whose ranges end at lessThan: 3.2.0, and unaffected by the 28 whose fixes landed at or before 3.1.62. Without normalization, the SBOM spelling GitPython would have matched 6 records and missed 28. The ?type=jar qualifier on the Maven purl is dropped before lookup.

What this does not handle: versionType values such as custom, git or distribution schemes (it flags them for review), changes arrays inside version ranges, purl types that need a repository-to-package mapping, and the order sensitivity of overlapping ranges. The CVE affected versions guide covers those rules in detail.

When the CVE has no purl

For the other 98% of records, you still need the older paths. The cpeApplicability explainer covers CPE-based matching, and collectionURL plus packageName is often enough to build a purl yourself: https://www.npmjs.com/package/x with packageName x is pkg:npm/x. Record which path produced each match, because a purl match and a name match deserve different confidence.

A match is only the start of the patch decision. In our vulnerability prioritization workflow, the purl join is the “does this apply to us” step; KEV, EPSS and SSVC decide how fast. If your supplier also ships VEX, apply it after the join; our CSAF VEX guide shows how to resolve its product IDs to purls.

Limits of this article

The counts describe one snapshot (the 5 November 2026 midnight bundle); CNAs update records, so the numbers will move. Month counts use each record’s original datePublished, so a purl added later to an old record is counted in the month the record was first published. We checked purl spelling only for the github and pypi rules; other types have their own normalization rules we did not test. We did not check how CVE Services validates purls at submission time. The join script uses Python’s packaging version ordering, which is close to, but not the same as, every ecosystem’s own ordering.

Sources and verification

Scope. This is a specification explainer with measurements from public data. We read the CVE Record Format schema on the CVEProject/cve-schema main branch (default dataVersion 5.2.0) and its advanced example record, sampled 2,000 random 2026 records from the cvelistV5 repository at commit f0b25a9 (November 4, 2026), and ran the Python script below with Python 3.13 against real records. We did not test commercial scanners or NVD’s own matching engine.

The short answer

cpeApplicability is where a CNA can say, in CPE terms, which configurations a CVE applies to. Each array element is one statement:

1. A statement has nodes, and optionally an operator and negate for combining them.
2. Each node has a required operator (AND or OR), an optional negate, and a cpeMatch list.
3. Each cpeMatch has a CPE 2.3 criteria string, a required vulnerable boolean, and optional bounds: versionStartIncluding, versionStartExcluding, versionEndIncluding, versionEndExcluding.
4. A host is in scope when the logic evaluates true against its CPE inventory and at least one matched entry has vulnerable: true.

If you already parse NVD configurations, the shape is familiar. The schema says so directly: the block is “mostly copied/forked from the NIST NVD CVE API v2.0 schema”.

Where the block lives

The schema defines cpeApplicability as an optional array on both the published CNA container and the ADP container. It was added in CVE Record Format 5.1.1 (the v5.1.1 tag in CVEProject/cve-schema dates from October 2024), which the release notes describe as adding “support for Common Platform Enumeration (CPE) Identifiers using the CPE Applicability Language”.

It is separate from the older cpes array inside each affected[] product. That array is a flat list of CPE names; its own schema description now ends: “Consider using the newer cpeApplicability block for defining CPE data using the CPE Applicability Language which includes more options for defining CPE Names.”

The schema adds one instruction that matters for consumers: “it is recommended that it align with (as much as possible) the product data provided within the affected block.” Recommended, not required. If you already read the affected block with the rules in our guide to lessThan, defaultStatus and versionType, treat cpeApplicability as a second encoding of the same claim, and expect the two to disagree sometimes.

The fields, one by one

Two details trip people up.

Version bounds apply only when the CPE’s version field is a wildcard. A criteria string such as cpe:2.3:a:ibm:mq_operator:3.4.1:*:... names one exact version; a string with * in the version position plus bounds names a range. Our evaluator treats a specific version in the criteria as an exact match and ignores bounds in that case.

There is no versionType. The affected block tells you whether versions are semver, git commits, or a custom scheme; cpeMatch does not. Whatever compares 6.18.9 with 6.19 has to guess the ordering, and for strings like alpha_0.3 or 1.3-beta there may be no safe guess.

AND, OR and vulnerable: false

The schema’s advanced example record shows the pattern that makes this block more expressive than a flat list. Its single element has "operator": "AND" and two nodes:

• Node 1 (OR): example_org:example_enterprise from 1.0.0 up to (excluding) 1.0.6, or from 2.1.6 up to 2.1.9, each with vulnerable: true.
• Node 2 (OR): Windows, macOS or a hardware model xt-4500, each with vulnerable: false.

Read it as: the application is vulnerable in those ranges when running on one of those platforms. The platform CPEs are conditions, not affected products. A tool that flags every host whose inventory contains cpe:2.3:o:microsoft:windows:... has misread the record.

What a sample of 2026 records contains

We took a seeded random sample of 2,000 files from the 84,849 2026 records in cvelistV5 at commit f0b25a9; 1,969 were published. The counting script parsed each record’s CNA and ADP containers.

Three practical readings. First, most records have no CPE statement from the CNA at all, so a CPE-only matcher misses most of the corpus. Second, the real-world block is simpler than the spec allows: almost everything is one OR node of ranges, and AND with platform CPEs is rare. Third, coverage depends on a handful of CNAs, so your hit rate will swing with your vendor mix. An earlier 1,000-record sample we took for the affected-versions guide found 29.5%; treat the figure as a range, not a constant.

The absence in ADP containers fits CISA’s stated policy. The Vulnrichment README says: “as of December 10, 2024, CISA will no longer be adding CPE strings to the enriched dataset.” See our explainer on CVE ADP containers for what CISA-ADP does still add.

A tested evaluator

The script takes one CVE record and every CPE installed on one host, and answers True, False or unknown. It is illustrative: it compares only dotted numeric versions, handles the \:-style escaping in CPE 2.3 names only for splitting, and matches part, vendor and product but ignores the remaining CPE fields.

"""Evaluate a CVE record's cna.cpeApplicability against one host's CPE inventory.
Illustrative: numeric-dotted versions only; anything else is reported as 'unknown'."""
import json, re, sys

def split_cpe(cpe):
    # split on ':' not preceded by a backslash (CPE 2.3 formatted-string escaping)
    return re.split(r'(?<!\\):', cpe)

def vkey(v):
    if not re.fullmatch(r'\d+(\.\d+)*', v):
        raise ValueError(v)
    return tuple(int(x) for x in v.split('.'))

def cmp(a, b):
    a, b = vkey(a), vkey(b)
    n = max(len(a), len(b))
    a, b = a + (0,) * (n - len(a)), b + (0,) * (n - len(b))
    return (a > b) - (a < b)

def match(m, installed_cpe):
    want, have = split_cpe(m['criteria']), split_cpe(installed_cpe)
    # compare part, vendor, product (fields 2-4); '*' is ANY
    for i in (2, 3, 4):
        if want[i] != '*' and want[i] != have[i]:
            return False
    ver = have[5]
    if want[5] not in ('*', '-'):            # exact version in the criteria
        return want[5] == ver
    checks = [('versionStartIncluding', lambda c: c >= 0), ('versionStartExcluding', lambda c: c > 0),
              ('versionEndIncluding', lambda c: c <= 0), ('versionEndExcluding', lambda c: c < 0)]
    return all(test(cmp(ver, m[k])) for k, test in checks if k in m)

def present(m, inventory):
    return any(match(m, c) for c in inventory)

def node(n, inv):
    hits = [present(m, inv) for m in n['cpeMatch']]
    r = all(hits) if n['operator'] == 'AND' else any(hits)
    return not r if n.get('negate') else r

def element(el, inv):
    res = [node(n, inv) for n in el['nodes']]
    r = all(res) if el.get('operator') == 'AND' else any(res)  # no operator: OR
    r = not r if el.get('negate') else r
    # the statement must also hit at least one entry flagged vulnerable
    vuln = any(m['vulnerable'] and present(m, inv)
               for n in el['nodes'] for m in n['cpeMatch'])
    return r and vuln

def evaluate(record, inventory):
    cna = record['containers']['cna']
    try:
        return any(element(el, inventory) for el in cna.get('cpeApplicability', []))
    except ValueError as e:
        return f'unknown (cannot order version {e})'

if __name__ == '__main__':
    rec = json.load(open(sys.argv[1]))
    inventory = sys.argv[2:]          # every CPE installed on one host
    print(' + '.join(inventory), '->', evaluate(rec, inventory))

Saved as cpe_eval.py, we ran it against three records from the sample and the schema’s example (output trimmed to the verdict):

$ python3 -I cpe_eval.py CVE-2026-74994.json 'cpe:2.3:a:erlang:erlang\/otp:28.5.0.5:*:*:*:*:*:*:*'
... -> True
$ python3 -I cpe_eval.py CVE-2026-74994.json 'cpe:2.3:a:erlang:erlang\/otp:28.5.0.6:*:*:*:*:*:*:*'
... -> False
$ python3 -I cpe_eval.py full-record-advanced-example.json cpe:2.3:a:example_org:example_enterprise:1.0.5:*:*:*:*:*:*:*
... -> False
$ python3 -I cpe_eval.py full-record-advanced-example.json cpe:2.3:a:example_org:example_enterprise:1.0.5:*:*:*:*:*:*:* cpe:2.3:o:microsoft:windows:11:*:*:*:*:*:*:*
... -> True
$ python3 -I cpe_eval.py CVE-2026-115975.json cpe:2.3:a:cervantessec:cervantes:v.1.4.0-beta:*:*:*:*:*:*:*
... -> unknown (cannot order version v.1.4.0-beta)

The Erlang/OTP record (CVE-2026-74994) is the common case: three ranges in one OR node, one per release line, with versionEndExcluding set to the fixed release. The example record shows the AND rule working: the application version alone is not enough; the platform must be present too. The Cervantes record (CVE-2026-115975) uses version strings like alpha_0.3 and 1.3-beta, and the honest answer is “cannot decide”.

Where cpeApplicability and affected disagree

CVE-2026-23122 is a Linux kernel record (published February 14, 2026). Its cpeApplicability block has one OR node with two ranges on cpe:2.3:o:linux:linux_kernel: 6.16 up to (excluding) 6.18.8, and 6.16 up to (excluding) 6.19. Its affected block for the semver product says 6.16 is affected, below 6.16 is unaffected, 6.18.8 through 6.18.* is unaffected, and 6.19 onwards is unaffected.

Our evaluator, run on kernel versions (output trimmed to the version and verdict):

6.15.4 -> False
6.18.7 -> True
6.18.9 -> True     # affected block: unaffected (6.18.8 to 6.18.*)
6.19   -> False

The second CPE range (6.16 to before 6.19) swallows the stable-branch fix, because a CPE range has no way to say “fixed in the 6.18 branch at 6.18.8 but not in mainline until 6.19”. The affected block can, through ordered entries and a 6.18.* upper limit. A scanner that trusts only CPE here raises a false positive on every patched 6.18 kernel.

That is the general lesson: CPE ranges are a lossy projection of branch-aware version data. Use them for discovery (which records mention a product I run?) and as a cross-check, then decide with the affected block.

Common mistakes

• Treating every matched CPE as vulnerable. Entries with vulnerable: false are context. In our sample they were rare (10 of 2,667), which is exactly why code that ignores the flag passes tests and fails later.
• Applying bounds to an exact-version criteria string. If the CPE’s version field is not *, compare it directly.
• Assuming the element operator. 84% of sampled elements omit it. With a single node it does not matter; with several, decide and document what your tool does. Our script treats a missing element operator as OR.
• Comparing versions as strings. "6.9" > "6.18" is true as text. Use a scheme-aware comparator and return “unknown” when the scheme is unknown.
• Mixing sources silently. CNA cpeApplicability, the older affected[].cpes, and NVD’s configurations are three different statements. Store which one produced a match.

Where this fits in triage

CPE matching answers “does this CVE apply to an asset I run?”. It does not answer “how urgently?”. Once a record matches, the next questions are whether it is in CISA KEV, its EPSS probability and its SSVC decision values; our vulnerability prioritization workflow walks that path from record to ticket, and the KEV JSON feed guide covers the exploitation check.

Limits of this article

• The counts come from one random sample of 2026 records at one commit; CNA behaviour changes, so rerun the count on your own snapshot before relying on a share.
• The evaluator is illustrative. It does not implement the full CPE 2.3 name-matching specification (NISTIR 7696), wildcard characters inside fields, or version schemes beyond dotted integers.
• We describe NVD configurations only by the schema’s own statement that this block was forked from the NVD CVE API v2.0 schema; we did not compare NVD’s published configurations for these CVEs.

Sources and verification

Scope. This is a field-level mapping guide. We compared the CycloneDX JSON schemas for 1.6 and 1.7 (identical enums for the fields below), OpenVEX specification v0.2.0 and its JSON schema, and the CSAF 2.0 JSON schema and VEX profile text from the OASIS TC repository, then read how Trivy (main branch, commit 1d1ab074, November 2, 2026) consumes CycloneDX VEX. The converter below was run with Python 3.13; its output validated against the OpenVEX 0.2.0 JSON schema and its inputs against the CycloneDX 1.6 schema. Our VEX explainer covers what the statuses mean and how far to trust them; this article is only about moving statements between formats.

The short answer

If you receive CycloneDX VEX and your pipeline speaks OpenVEX or CSAF (or the reverse), the states map almost one-to-one, but the justifications do not.

Of CycloneDX’s nine justifications, only code_not_present and code_not_reachable have a clear counterpart among the five CISA-derived labels that OpenVEX and CSAF share. Convert those two; carry the other seven as text.

Where VEX sits in a CycloneDX document

CycloneDX has no separate VEX document type. VEX is the vulnerabilities array of a BOM, and the fields that matter are:

• id: the vulnerability identifier, such as a CVE ID.
• affects[].ref: what the statement is about. The schema allows a bom-ref in the same document or a BOM-Link element. A BOM-Link has the form urn:cdx:serialNumber/version#bom-ref, and the schema’s pattern requires the serial number UUID, a version of 1 or more, and a fragment.
• analysis.state: one of resolved, resolved_with_pedigree, exploitable, in_triage, false_positive, not_affected.
• analysis.justification: one of nine reasons, described below.
• analysis.response: zero or more of can_not_fix, will_not_fix, update, rollback, workaround_available.
• analysis.detail: free text. The schema says that if a vulnerability is not exploitable, “this field should include specific details on why the component or service is not impacted.”

A VEX statement can sit inside the SBOM itself or in a separate BOM that only has vulnerabilities and refers back to the SBOM by BOM-Link. That second pattern matters for tooling, below.

States: four clean pairs and two lossy ones

The CycloneDX schema defines the six states in its meta:enum. Four map directly:

• not_affected: “The component or service is not affected by the vulnerability. Justification should be specified for all not_affected cases.” This is OpenVEX not_affected and CSAF known_not_affected.
• exploitable: “The vulnerability may be directly or indirectly exploitable.” This is OpenVEX affected and CSAF known_affected.
• in_triage: “The vulnerability is being investigated.” This is under_investigation in both.
• resolved: “The vulnerability has been remediated.” This is fixed in both.

Two lose meaning:

• false_positive: “The vulnerability is not specific to the component or service and was falsely identified or associated.” OpenVEX and CSAF have no status for “the scanner was wrong”. The safe target is not_affected, which is also what Trivy’s cdxStatus function does (case cdx.IASFalsePositive, cdx.IASNotAffected: return types.FindingStatusNotAffected). Keep the word false_positive in the impact statement so a reviewer can see it.
• resolved_with_pedigree: remediated “and evidence of the changes are provided in the affected components pedigree”. It becomes fixed, and the pointer to pedigree evidence is lost unless you keep it as text.

Justifications: two of nine line up

OpenVEX’s five justification labels come from CISA’s June 2022 status-justification document, and the CSAF 2.0 schema’s flags[].label uses the same five strings. CycloneDX defines a different set of nine. Here is each one with its CycloneDX definition and our reading of the closest OpenVEX/CSAF label.

Why so strict? The OpenVEX spec defines inline_mitigations_already_exist as built-in protections that “cannot be subverted by the attacker and cannot be configured or disabled by the user.” A CycloneDX protected_at_runtime or protected_by_compiler claim does not tell you that. protected_at_perimeter and protected_by_mitigating_control describe the deployment, not the product, and a mitigating control that “reduce[s] the likelihood and/or impact” is weaker than “not affected” in the CISA sense.

This mapping is our editorial reading of the published definitions. We did not find a mapping table published by the CycloneDX project or CISA.

OpenVEX gives you a way out: for not_affected, “a VEX statement MUST include either a status justification or an impact_statement.” So you can emit a not_affected statement with no label and an impact statement that preserves the original CycloneDX reason. CSAF’s VEX profile has the same escape hatch: each known_not_affected product needs either a machine-readable flag or a human-readable justification in threats with category impact.

Responses and action statements

For affected products, both targets require an action:

• OpenVEX: for affected, “a VEX statement MUST include a statement that SHOULD describe actions to remediate or mitigate the vulnerability” (action_statement).
• CSAF VEX profile: for known_affected, “additional product specific information SHALL be provided in /vulnerabilities[]/remediations as an action statement.”

CycloneDX’s response values give you a starting point. update and rollback fit CSAF’s vendor_fix remediation category, workaround_available fits workaround, and will_not_fix / can_not_fix fit no_fix_planned (or none_available), which the CSAF profile explicitly permits for an action statement. OpenVEX takes a free-text action_statement, so join the responses with analysis.detail. If an exploitable statement has neither a response nor detail, the converted statement will be valid but useless; send it back to the supplier.

BOM-Link: the part that silently drops statements

A CycloneDX VEX BOM that references components by BOM-Link is bound to one SBOM version. Trivy’s docs (v0.67) say the tool “only supports the Independent BOM and VEX BOM format, so you need to provide a separate VEX file alongside the SBOM,” that “BOM-Links must be placed in affects.ref,” and that the input SBOM must be CycloneDX. The usage example is trivy sbom trivy.sbom.cdx --vex trivy.vex.cdx. The feature is marked experimental.

Trivy’s code adds a detail the docs do not spell out: if the BOM-Link’s serial number or version does not equal the scanned SBOM’s, it logs URN doesn't match with SBOM and skips the statement. Regenerate the SBOM (new serial number or version) without regenerating the VEX, and every suppression stops applying. That fails safe, since findings come back rather than disappear, but it surprises teams.

OpenVEX has no BOM-Link. Products are identified by an @id such as a Package URL, so a converter has to resolve each BOM-Link to the referenced component’s purl in the SBOM. That is why the converter below takes both files.

A tested converter: CycloneDX VEX to OpenVEX

This Python 3 script reads a CycloneDX SBOM and a separate CycloneDX VEX BOM and writes an OpenVEX 0.2.0 document. It maps states as in the first table, maps only the two clean justifications, and keeps everything else as text. It is illustrative, not production-ready: it does not handle version ranges in affects[].versions, services, or nested BOMs beyond components.

#!/usr/bin/env python3
"""Convert a CycloneDX VEX BOM (independent VEX, BOM-Link refs) to OpenVEX v0.2.0.
Usage: python3 cdx2openvex.py sbom.cdx.json vex.cdx.json author > out.openvex.json"""
import json, sys, hashlib
from datetime import datetime, timezone

STATUS = {  # CycloneDX analysis.state -> OpenVEX status
    "not_affected": "not_affected", "false_positive": "not_affected",
    "exploitable": "affected", "in_triage": "under_investigation",
    "resolved": "fixed", "resolved_with_pedigree": "fixed",
}
# Only the pairs whose definitions line up; everything else is carried as text.
JUSTIFICATION = {
    "code_not_present": "vulnerable_code_not_present",
    "code_not_reachable": "vulnerable_code_not_in_execute_path",
}

def purls_by_ref(sbom):
    serial, version = sbom["serialNumber"], sbom.get("version", 1)
    out, stack = {}, list(sbom.get("components", []))
    while stack:
        c = stack.pop()
        if "bom-ref" in c and "purl" in c:
            out[f"urn:cdx:{serial.removeprefix('urn:uuid:')}/{version}#{c['bom-ref']}"] = c["purl"]
        stack.extend(c.get("components", []))
    return out

def convert(sbom, vex, author):
    refs, statements, problems = purls_by_ref(sbom), [], []
    for v in vex.get("vulnerabilities", []):
        a = v.get("analysis", {})
        state = a.get("state")
        if state not in STATUS:
            problems.append(f"{v['id']}: no analysis.state, skipped"); continue
        products = []
        for af in v.get("affects", []):
            purl = refs.get(af["ref"])
            if purl: products.append({"@id": purl})
            else: problems.append(f"{v['id']}: {af['ref']} not found in SBOM")
        if not products: continue
        s = {"vulnerability": {"name": v["id"]}, "products": products, "status": STATUS[state]}
        detail = a.get("detail", "").strip()
        if s["status"] == "not_affected":
            j = JUSTIFICATION.get(a.get("justification"))
            if j: s["justification"] = j
            note = f"CycloneDX state={state}, justification={a.get('justification', 'none')}"
            s["impact_statement"] = f"{note}. {detail}".strip()
        elif s["status"] == "affected":
            resp = ", ".join(a.get("response", [])) or "none given"
            s["action_statement"] = f"CycloneDX response: {resp}. {detail}".strip()
        statements.append(s)
    body = json.dumps(statements, sort_keys=True).encode()
    doc = {"@context": "https://openvex.dev/ns/v0.2.0",
           "@id": "https://example.com/vex/" + hashlib.sha256(body).hexdigest()[:16],
           "author": author,
           "timestamp": datetime.now(timezone.utc).isoformat(timespec="seconds"),
           "version": 1, "statements": statements}
    return doc, problems

if __name__ == "__main__":
    sbom, vex = (json.load(open(p)) for p in sys.argv[1:3])
    doc, problems = convert(sbom, vex, sys.argv[3])
    json.dump(doc, sys.stdout, indent=2)
    for p in problems: print("WARN", p, file=sys.stderr)

Test run

We fed it a three-component CycloneDX 1.6 SBOM (log4j-core 2.14.1, jackson-databind 2.13.0, snakeyaml 1.30) and a VEX BOM with four statements. The assessments in the VEX are invented test data, not real vendor findings:

1. CVE-2021-44228 on log4j-core: not_affected, code_not_reachable.
2. CVE-2022-42003 on jackson-databind: not_affected, requires_configuration.
3. CVE-2022-1471 on snakeyaml: exploitable, response update.
4. CVE-2021-44228 again, but with a BOM-Link naming SBOM version 2 instead of 1.

Both input files passed check-jsonschema against the CycloneDX 1.6 schema. The run printed one warning to stderr and three statements; the output validated against openvex_json_schema.json (v0.2.0) with the Python jsonschema package:

WARN CVE-2021-44228: urn:cdx:3e671687-395b-41f5-a30f-a58921a69b79/2#pkg-log4j not found in SBOM

The statements array of the output:

[
{
  "vulnerability": { "name": "CVE-2021-44228" },
  "products": [ { "@id": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1" } ],
  "status": "not_affected",
  "justification": "vulnerable_code_not_in_execute_path",
  "impact_statement": "CycloneDX state=not_affected, justification=code_not_reachable. JNDI lookups are never invoked; the app logs through SLF4J with Logback."
},
{
  "vulnerability": { "name": "CVE-2022-42003" },
  "products": [ { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.0" } ],
  "status": "not_affected",
  "impact_statement": "CycloneDX state=not_affected, justification=requires_configuration. The deserialization feature this issue depends on is disabled in our ObjectMapper configuration."
},
{
  "vulnerability": { "name": "CVE-2022-1471" },
  "products": [ { "@id": "pkg:maven/org.yaml/snakeyaml@1.30" } ],
  "status": "affected",
  "action_statement": "CycloneDX response: update. Dependency upgrade ships in release 4.2."
}
]

The second statement is the important one: it stays not_affected with no invented label, and the reason survives as text. The fourth input statement was dropped with a warning instead of being applied to the wrong SBOM.

Common mistakes

• Mapping every protected_* justification to inline_mitigations_already_exist. That label claims the protection cannot be disabled. A WAF rule or a compiler flag can.
• Dropping false_positive statements because the target format has no matching status. Map them to not_affected and say why.
• Dropping the detail text. It is often the only evidence a reviewer has, and both OpenVEX and CSAF have a place for it.
• Reusing a VEX BOM after regenerating the SBOM. BOM-Links name an exact serial number and version.
• Treating converted VEX as first-party. Keep the original author. OpenVEX author should be the organization that made the assessment, not the converter.

Where this fits

VEX is the “is my product actually affected” step in our vulnerability prioritization workflow, after the CVE record and before KEV, SSVC and EPSS. The SBOM that the VEX points at is covered in our guide to SBOM minimum elements in 2026. If you want a signal for which exploitable statements to fix first, our CVSS vs EPSS vs KEV comparison covers the trade-offs.

Limits of this article

The justification mapping is our reading of the published definitions; no standards body has published it. We read CSAF 2.0 from the OASIS TC’s GitHub repository (schema and editor’s draft prose) rather than the OASIS-hosted standard. We read Trivy’s main branch, not a tagged release, and its docs for v0.67; behaviour may differ in the version you run. We did not run Trivy itself or test the reverse conversion (OpenVEX or CSAF to CycloneDX), which is harder because CycloneDX affects needs a component reference the OpenVEX product may not resolve to.

Sources and verification

A static cloud credential — an AWS access key, a GCP service account key — stored as a GitHub Actions secret has one fundamental property that makes it a standing risk: it remains valid until someone actively notices it shouldn’t be and rotates it. OpenID Connect (OIDC) support in GitHub Actions removes that credential from the equation entirely, replacing it with a token that’s short-lived by design and requires no manual rotation discipline to stay safe.

How the exchange actually works

When a workflow configured for OIDC runs, GitHub’s Actions runner requests a JSON Web Token (JWT) from GitHub’s own OIDC provider (token.actions.githubusercontent.com). This token contains claims about the workflow run — which repository, which branch or ref, which workflow file — and is signed by GitHub. The workflow then presents this token to the cloud provider (AWS STS, for example), which has been configured ahead of time to trust GitHub’s OIDC provider and to check specific claims in the token before issuing temporary credentials. If the claims match what the trust policy expects, the cloud provider issues short-lived, scoped credentials good only for that specific workflow run.

No static credential is stored anywhere in this flow. The only thing GitHub holds is a role ARN or equivalent identifier telling it which role to request — the actual authentication happens fresh, per run, through the signed token exchange.

Setting up the AWS side of the trust relationship

Configuring this requires two things in AWS: registering GitHub’s OIDC provider as a trusted identity provider in IAM, and creating an IAM role with a trust policy that specifies exactly which GitHub repositories (and optionally, which branches or environments) are allowed to assume it. A typical trust policy condition restricts the sub claim to a specific pattern like repo:your-org/your-repo:ref:refs/heads/main, meaning only workflow runs on that exact branch, in that exact repository, can successfully assume the role — a workflow run from a fork, or from a different branch, will have a token with a sub claim that doesn’t match, and the assume-role call will simply fail.

This scoping is what makes OIDC meaningfully more secure than a static credential even beyond the “no long-lived secret” property — the trust relationship itself constrains which workflows can even attempt to use it, rather than relying on the credential’s holder being trustworthy by assumption.

The workflow-side configuration

The workflow needs explicit permissions: id-token: write set — this is the permission that allows the job to request an OIDC token from GitHub in the first place, and it’s not granted by default even when other broad permissions are set. Combined with an action like aws-actions/configure-aws-credentials, specifying the target role’s ARN, the workflow requests the token, performs the exchange with AWS STS, and receives temporary credentials scoped to that role — all without a static AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY appearing anywhere in the workflow or in GitHub’s secret storage.

Why the “short-lived” property matters beyond convenience

A leaked static credential is a live problem until someone notices and rotates it — which could be minutes or months, depending entirely on whether monitoring catches the exposure. An OIDC-issued credential, even if somehow captured mid-flight during a specific run, expires on its own shortly after that run completes, typically within the hour. This changes the actual risk calculus: the attacker’s usable window is bounded by design, rather than bounded by however quickly your team happens to detect and respond to a leak.

What OIDC does not solve

OIDC removes the specific risk of a long-lived credential leaking from CI storage. It doesn’t address other CI/CD security concerns: a compromised workflow can still assume the role and act with whatever permissions that role grants during its valid window, so scoping the IAM role’s own permissions narrowly still matters exactly as much as it did with static credentials. It also doesn’t protect against a malicious pull request modifying the workflow file itself to add unauthorized steps, if the workflow’s trigger configuration allows untrusted code to influence what runs — that’s a separate class of risk (pull_request_target misuse, in particular) that OIDC doesn’t touch.

Multi-cloud and cross-provider considerations

AWS, Google Cloud, and Azure all support this pattern under slightly different names (AWS calls it “Web Identity Federation,” GCP calls it “Workload Identity Federation”) but the underlying mechanism — trusting GitHub’s OIDC provider and issuing short-lived credentials based on token claims — is conceptually the same across all three. If your pipeline deploys to multiple clouds, this pattern is worth implementing consistently across all of them rather than only for whichever provider had the most convenient existing tutorial.

A practical checklist

• Register GitHub’s OIDC provider in your cloud provider’s IAM configuration
• Write the trust policy’s conditions narrowly — specific repository, specific branch or environment, not a broad wildcard match
• Set permissions: id-token: write explicitly on any workflow using OIDC
• Remove any existing static cloud credentials stored as GitHub secrets once OIDC is confirmed working, rather than leaving both in place indefinitely
• Scope the IAM role’s own permissions narrowly — OIDC changes how the credential is obtained, not how much access the resulting credential should have

Migrating from static credentials to OIDC is one of the highest-leverage changes available for CI/CD security, precisely because it eliminates an entire category of leak (a long-lived secret sitting in storage) rather than just making that category harder to exploit.

Scope. This is a specification explainer with measurements from public data. We read the CVE JSON schema (version 5.2.0, CVEProject/cve-schema main branch) and its version-encoding guide, sampled 1,000 random 2026 records from the cvelistV5 repository at commit 451e97a (November 2, 2026), and ran the Python script below against real records. We did not test commercial scanners.

The short answer

A CVE record’s affected block does not hand you a list of bad versions. For each product it gives a small decision procedure:

1. Walk the versions list in order.
2. An entry with only version and status matches that exact version.
3. An entry with versionType plus lessThan or lessThanOrEqual matches a range, and an optional changes list can flip the status partway through it.
4. The first matching entry wins. If nothing matches, the answer is defaultStatus, and if that is missing, the answer is unknown.

The possible answers are affected, unaffected and unknown. Your tooling needs a fourth, “I cannot order these versions”, because the record does not always give you enough to decide.

Where the fields live

The CNA (CVE Numbering Authority) writes containers.cna.affected, an array of product objects. The schema requires each product to be identified by either vendor and product or collectionURL and packageName, and to carry versions, defaultStatus or both. A 5.2 record can also carry a packageURL (a purl, which the schema says must not include a version).

{
  "vendor": "GitoxideLabs",
  "product": "gitoxide",
  "defaultStatus": "unaffected",
  "packageURL": "pkg:cargo/gix-fs",
  "versions": [
    {"version": "0", "status": "affected", "versionType": "semver", "lessThan": "0.23.0"},
    {"version": "0.23.0", "status": "unaffected", "versionType": "semver"}
  ]
}

That is the product entry from CVE-2026-100419 (a gix-fs symlink worktree escape), shown in full. Read it as: semantic versions from 0 up to but not including 0.23.0 are affected, 0.23.0 is unaffected, and anything else is unaffected by default.

The fields, one by one

The upper limit can end in *, which the schema defines as “an arbitrarily large number in the version ordering”. {version: 1.0, lessThan: 1.*} describes the whole 1.x branch, and lessThan: * means “and everything after”.

Why versionType is not optional

The schema guide explains that “there is no single definition of ’less than’ for versions” and gives the example that in semantic versioning 1.0.0-cr1 sorts before 1.0.0-m1, while in Maven the opposite is true. If your code compares every version string with one generic routine, it will be wrong for some ecosystems.

The guide is blunt about custom: it “means that the version status algorithm cannot be executed, so its use is discouraged”. It exists to convert older data.

Three records, three encodings

Allow-list style (gix-fs, CVE-2026-100419). The range is affected and defaultStatus is unaffected. Version 0.22.1 is affected, 0.23.0 is unaffected by exact match, and 0.25.4 is unaffected by default.

List without a default (quickjs, CVE-2026-0821). The CNA lists eleven single versions from 0.1 to 0.11.0 as affected and sets no defaultStatus. Version 0.10 is affected. Version 0.12.0 is unknown: the record makes no claim about it. A naive matcher that treats “not listed” as “not affected” would clear it.

Deny-list style (Linux, CVE-2026-100075). The second product entry sets "defaultStatus": "affected" and lists unaffected ranges per stable branch:

{"version": "4.7", "status": "affected"},
{"version": "0", "lessThan": "4.7", "status": "unaffected", "versionType": "semver"},
{"version": "6.6.157", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"},
{"version": "7.3", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}

(Excerpt; the record also lists 5.10, 5.15, 6.1, 6.12, 6.18 and 7.2 branches.) Kernels before 4.7 are unaffected, 6.6.157 and later 6.6 releases are unaffected, and anything not covered, such as 6.6.150 or a 5.4 kernel, falls through to affected. The first product entry in the same record describes the same flaw with versionType: git commit ranges, which you cannot evaluate without the kernel’s commit history.

What a sample of 2026 records contains

We drew 1,000 CVE IDs at random (seeded) from the 83,665 record files under cves/2026 at cvelistV5 commit 451e97a. 16 were REJECTED; the 984 published records held 2,061 product entries, 4,555 version entries and 2,831 ranges. Counts were computed with a Python script over the JSON.

Two numbers matter most for automation. More than half of product entries leave unlisted versions as unknown, and about a third of ranges use custom, so a generic comparator cannot decide them. This is one sample at one point in time; the mix varies by CNA, and a different year or sample would give different shares.

A tested evaluator

The script implements the schema’s algorithm. It handles dotted numeric versions (so 1.2.10 sorts after 1.2.9) and *, and it refuses any range whose versionType it has not been told how to order. It does not implement semver pre-release ordering, RPM epochs or Maven qualifiers; treat it as a reference, not a drop-in matcher. Python 3.10 or later, standard library only.

#!/usr/bin/env python3
"""Decide affected / unaffected / unknown for one product version from a CVE record,
following the algorithm in the CVE JSON 5 schema (product.versions + defaultStatus).
Usage: affected_status.py RECORD.json VERSION [vendor/product filter] [--numeric TYPE,...]
"""
import json, sys

SUPPORTED = {"semver"}  # extend with real comparators (rpm, maven, python...) before use

def key(v):
    parts = []
    for p in v.split("."):
        if p == "*":
            parts.append(float("inf"))
        elif p.isdigit():
            parts.append(int(p))
        else:
            raise ValueError(f"non-numeric version part {p!r} in {v!r}")
    return parts

def cmp(a, b):
    ka, kb = key(a), key(b)
    n = max(len(ka), len(kb))
    # pad: a missing part is 0, except after a wildcard, which stays infinite
    ka += [float("inf") if ka and ka[-1] == float("inf") else 0] * (n - len(ka))
    kb += [float("inf") if kb and kb[-1] == float("inf") else 0] * (n - len(kb))
    return (ka > kb) - (ka < kb)

def status(product, v):
    for e in product.get("versions", []):
        is_range = "lessThan" in e or "lessThanOrEqual" in e
        if not is_range:
            if v == e["version"]:
                return e["status"], "exact match"
            continue
        vt = e.get("versionType")
        if vt not in SUPPORTED:
            return "undetermined", f"range uses versionType {vt!r}; needs that ordering"
        lo_ok = cmp(e["version"], v) <= 0
        hi_ok = (cmp(v, e["lessThan"]) < 0) if "lessThan" in e else (cmp(v, e["lessThanOrEqual"]) <= 0)
        if lo_ok and hi_ok:
            s = e["status"]
            for c in sorted(e.get("changes", []), key=lambda c: key(c["at"])):  # schema: re-sort yourself
                if cmp(c["at"], v) <= 0:
                    s = c["status"]
            return s, "range match"
    return product.get("defaultStatus", "unknown"), "defaultStatus" + ("" if "defaultStatus" in product else " (absent, so unknown)")

if __name__ == "__main__":
    args = sys.argv[1:]
    if "--numeric" in args:  # opt-in: treat these extra versionTypes as dotted numeric
        i = args.index("--numeric")
        SUPPORTED.update(args[i + 1].split(","))
        del args[i:i + 2]
    sys.argv[1:] = args
    rec = json.load(open(sys.argv[1]))
    version = sys.argv[2]
    want = sys.argv[3].lower() if len(sys.argv) > 3 else ""
    if rec["cveMetadata"]["state"] != "PUBLISHED":
        sys.exit(f"{rec['cveMetadata']['cveId']} is {rec['cveMetadata']['state']}")
    for i, p in enumerate(rec["containers"]["cna"].get("affected", [])):
        name = f"{p.get('vendor', '')}/{p.get('product', p.get('packageName', ''))}"
        if want and want not in name.lower():
            continue
        print(f"{rec['cveMetadata']['cveId']} [{i}] {name} {version}: %s (%s)" % status(p, version))

We ran it with Python 3.13 on November 2, 2026 against records downloaded from cvelistV5 (raw.githubusercontent.com/CVEProject/cvelistV5/<commit>/cves/2026/<block>/<CVE>.json). Selected output:

CVE-2026-100419 [0] GitoxideLabs/gitoxide 0.22.1: affected (range match)
CVE-2026-100419 [0] GitoxideLabs/gitoxide 0.23.0: unaffected (exact match)
CVE-2026-100419 [0] GitoxideLabs/gitoxide 0.25.4: unaffected (defaultStatus)
CVE-2026-0821 [0] quickjs-ng/quickjs 0.12.0: unknown (defaultStatus (absent, so unknown))
CVE-2026-100075 [0] Linux/Linux 6.6.150: undetermined (range uses versionType 'git'; needs that ordering)
CVE-2026-100075 [1] Linux/Linux 6.6.150: undetermined (range uses versionType 'original_commit_for_fix'; needs that ordering)
CVE-2026-103345 [0] Shamim Rajani/Pie Register 3.8.4.13: undetermined (range uses versionType 'custom'; needs that ordering)
CVE-2026-23915 is REJECTED

The Linux result is the instructive one. For 6.6.150 the evaluator reaches the 7.3 ... * entry, whose versionType is original_commit_for_fix, a value that is not among the schema’s examples. A strict implementation stops there. If you decide, for this CNA’s data, that those values are ordinary kernel version numbers, you can opt in with --numeric original_commit_for_fix, and the second product entry then gives 4.4.302 unaffected, 4.7 affected, 6.6.150 affected (by defaultStatus), 6.6.157 unaffected and 7.3 unaffected. That opt-in is our judgment about one CNA’s encoding, not something the schema states.

Common mistakes

• Treating “not listed” as “not affected”. Without defaultStatus: unaffected, unlisted versions are unknown.
• Off-by-one on the upper bound. lessThan: 0.23.0 excludes 0.23.0; lessThanOrEqual: 3.8.4.13 includes 3.8.4.13.
• Comparing strings. As text, “0.10” sorts before “0.9”. Parse versions with the ecosystem’s rules.
• Assuming changes is sorted. The schema tells clients to re-sort.
• Reading only the first product entry. The same record can describe a product twice, as the Linux record does with git ranges and version ranges.
• Ignoring the record state. A REJECTED record has no affected block to evaluate; see CVE record states.

Where this fits in triage

Version matching answers “do we run an affected version?”, which comes before any priority signal. If the answer is unknown or undetermined, check the vendor advisory, or a supplier VEX statement that says whether the product is affected (see how to read a VEX not-affected statement). An SBOM with accurate component versions is what makes this lookup possible at scale; our summary of the 2026 SBOM minimum elements covers what to ask suppliers for. Once a finding is confirmed as affected, our vulnerability prioritization workflow takes it from record to ticket using KEV, EPSS and SSVC.

Limits of this article

The sample covers 2026 records only and reflects the repository on November 2, 2026; CNAs update records, so shares will drift. Our evaluator is a reference implementation of the schema’s algorithm for numeric versions, not a full comparator for semver pre-releases, RPM, Maven, Python or git ranges. We did not examine ADP containers, which can carry their own affected data (15 of the 984 sampled records had one), or NVD’s separate CPE configurations.

Sources and verification

A GitHub Actions workflow, by default, often runs with more access than the task it performs actually requires — not because anyone deliberately over-provisioned it, but because the defaults are permissive and narrowing them down takes deliberate configuration that’s easy to skip while getting a pipeline working.

Scope the GITHUB_TOKEN’s permissions explicitly

Every workflow run gets an automatically generated GITHUB_TOKEN with permissions to the repository, and its default scope has historically been broad (write access to most repository resources) unless explicitly restricted. Setting explicit permissions at the workflow or job level — for example, contents: read for a job that only needs to check out code, without write access it doesn’t use — limits what a compromised or misbehaving step in that workflow could actually do. Treat “no permissions block at all” as equivalent to “unreviewed, possibly excessive default access,” and set it explicitly on every workflow rather than relying on whatever the default happens to be.

Third-party actions run with your workflow’s access

An action referenced with uses: someorg/some-action@v1 executes with the same permissions and secrets access as the rest of your workflow — it isn’t sandboxed away from your repository’s context. A compromised or malicious action has the same practical reach as a line of code you wrote directly into the workflow yourself. Pin third-party actions to a specific commit SHA rather than a mutable version tag; a tag can be moved to point at different code without your workflow file changing at all, while a commit SHA cannot be silently swapped underneath you.

Be deliberate about pull_request vs pull_request_target

Workflows triggered by pull_request from a fork do not have access to repository secrets by default — this is intentional, specifically to prevent a malicious fork PR from exfiltrating secrets through a workflow run. pull_request_target, by contrast, does grant secrets access and runs with the target repository’s permissions, which is necessary for some legitimate use cases (like commenting on PRs from forks) but requires careful handling of any code checked out from the fork, since that code is now running with elevated access it wouldn’t otherwise have. Mixing this up — using pull_request_target without the corresponding caution around what fork-supplied code gets executed — is a well-documented way workflows get exploited.

OIDC removes the need for long-lived cloud credentials entirely

Storing static cloud credentials (an AWS access key, a GCP service account key) as a GitHub secret means that credential is a standing target — if it leaks, through any of the usual channels, it remains valid until someone notices and manually rotates it. GitHub Actions supports OpenID Connect (OIDC), which lets a workflow request a short-lived token from GitHub’s OIDC provider and exchange it for temporary cloud credentials at request time, without any static credential stored in GitHub at all. AWS, GCP, and Azure all support configuring a trust relationship that allows this exchange, scoped to specific repositories or even specific branches.

This is a meaningfully different security posture, not just a convenience improvement: there’s no long-lived credential to leak, because none exists in GitHub’s secret storage in the first place — the token issued for each workflow run is scoped to that run and expires shortly after.

Secrets scoping beyond just using GitHub Secrets

Even with secrets correctly stored (rather than hardcoded), using repository-level secrets for everything means every workflow in the repo has access to every secret, regardless of whether that specific workflow needs it. GitHub’s environment-level secrets, combined with required reviewers or branch restrictions on that environment, let you scope a deployment credential so it’s only accessible to workflow runs specifically targeting a protected environment — meaningfully narrower than blanket repository-level access.

Reusable and self-hosted runner risks

Self-hosted runners execute workflow code on infrastructure you control, which means a compromised workflow (through a malicious PR, a compromised dependency pulled in during the job, or a compromised action) can potentially affect that underlying infrastructure directly, not just an ephemeral GitHub-hosted VM that’s destroyed after the run. If self-hosted runners are used for anything handling untrusted input (like workflows triggered by external contributions), the isolation and cleanup between runs needs explicit attention that GitHub-hosted runners provide automatically.

A practical checklist

• Set explicit, minimal permissions on every workflow rather than relying on defaults
• Pin third-party actions to a commit SHA, not a mutable tag
• Understand the secrets-access difference between pull_request and pull_request_target, and handle fork-supplied code with corresponding caution in the latter
• Adopt OIDC for cloud provider authentication instead of storing long-lived static credentials as secrets
• Use environment-level secrets with protection rules for anything tied to deployment, rather than defaulting to repository-level scope
• Treat self-hosted runner isolation as something requiring explicit configuration, not something GitHub-hosted runners’ automatic cleanup provides for you

None of these individually make a pipeline “secure” — together, they reduce a CI/CD system’s blast radius from “one compromised link exposes everything” to something meaningfully more contained.

Search features have a habit of taking a user’s text and dropping it straight into a pattern: new RegExp(query), re.search(term, line), WHERE name LIKE '%' || $1 || '%'. The user meant “find this text”. The engine reads “match this pattern”. A dot becomes “any character”, .* becomes “everything”, and % in a LIKE search returns every row you were filtering.

The short answer: when user text should match literally, escape it with the platform function (re.escape, RegExp.escape, regexp.QuoteMeta) before building the pattern. For SQL LIKE, bind the value as a parameter and escape \, % and _ in it, with an explicit ESCAPE '\'. If the text is also used as a replacement string, pass a function, not a string.

This article is about user text that should be treated as literal. If your product lets users write real regular expressions, escaping is the wrong tool; see User-Supplied Regex: How to Run It Without ReDoS.

What goes wrong without escaping

We ran each example below and show the output. Test environment: Python 3.13.18, Node.js 24.22.2 (V8 13.6) and 22.23.4, Go 1.24.7, SQLite 3.53.1 (Python’s sqlite3 module) and PostgreSQL 16.15, all on Linux.

# Python 3.13: search log lines for a user-supplied term
import re
logs = ["user=alice", "user=al.ce", "user=bob", "user=admin"]

q = "al.ce"
[l for l in logs if re.search(q, l)]             # ['user=alice', 'user=al.ce']
[l for l in logs if re.search(re.escape(q), l)]  # ['user=al.ce']

q = ".*"
all(re.search(q, l) for l in logs)               # True: matches every line
[l for l in logs if re.search(re.escape(q), l)]  # []

The consequences depend on where the pattern is used. In a search box it is a wrong result. In a filter that decides which records a user may see, a match against tenant or account names, or a log-redaction rule, a wildcard where you expected a literal is an authorisation or data-exposure bug. Unescaped input also lets the user add nested quantifiers to your pattern, which is a route to ReDoS in backtracking engines.

Regex: use the platform escaper

Python: re.escape

The Python docs describe re.escape as escaping “special characters in pattern”, useful “if you want to match an arbitrary literal string that may have regular expression metacharacters in it.” Since Python 3.7, “only characters that can have special meaning in a regular expression are escaped.”

re.escape("a.b*c(d)")   # 'a\\.b\\*c\\(d\\)'
pattern = re.compile(r"\b" + re.escape(user_term) + r"\b", re.IGNORECASE)

Go: regexp.QuoteMeta

Go’s QuoteMeta “returns a string that escapes all regular expression metacharacters inside the argument text; the returned string is a regular expression matching the literal text.”

// Go 1.24.7
fmt.Println(regexp.QuoteMeta("al.ce*(x)"))                                  // al\.ce\*\(x\)
fmt.Println(regexp.MustCompile(regexp.QuoteMeta("al.ce")).MatchString("alice")) // false

JavaScript: RegExp.escape, and why the old snippet is not enough

MDN describes RegExp.escape() as returning “a new string that can be safely used as a literal pattern for the RegExp() constructor”, and marks it Baseline 2025. It is present in Node.js 24 and absent in Node.js 22:

node v24.22.2 RegExp.escape: function
node v22.23.4 RegExp.escape: undefined

The output looks odd at first: RegExp.escape("foo.bar") returns \x66oo\.bar. MDN explains that a leading digit or ASCII letter is written as a \x escape so that, if the result is “immediately preceded by \1, \x0, \u000, etc., the leading character doesn’t get interpreted as part of the escape sequence.” Other punctuators such as - are also written as \x escapes.

That is exactly where the widely copied replace-based escaper falls short. We compared the two in Node.js 24:

// Node.js 24.22.2
const escapeRegExp = s => s.replace(/[.*+?^${}()|[\]\\]/g, "\\$&"); // common fallback

// 1. User text placed right after a backreference
new RegExp("(a)\\1" + escapeRegExp("1")).source;   // '(a)\\11'  -> test("aa1") is false
new RegExp("(a)\\1" + RegExp.escape("1")).source;  // '(a)\\1\\x31' -> test("aa1") is true

// 2. User text placed inside a character class
new RegExp("[" + escapeRegExp("a-z") + "]").test("m");   // true: became the range a-z
new RegExp("[" + RegExp.escape("a-z") + "]").test("m");  // false: matches only a, -, z

In both cases the fallback produced a valid pattern that matched something different from what was intended. MDN’s advice is direct: “don’t try to re-implement its functionality,” because RegExp.escape() “is designed to use escape sequences that work in many more edge cases/contexts than hand-crafted code is likely to achieve.”

For code that must also run on older runtimes:

// Prefer the built-in; the fallback is only safe when the escaped text
// is not placed inside [...] or directly after a backslash escape.
const escapeRegExp = typeof RegExp.escape === "function"
  ? RegExp.escape
  : s => s.replace(/[.*+?^${}()|[\]\\]/g, "\\$&");

Escaping does not cover the replacement string

Teams that escape the pattern often forget that the replacement argument has its own syntax.

JavaScript. In String.prototype.replace, a replacement string interprets $&, $1, $<name> and similar. A function’s return value is used as is:

// Node.js 24.22.2
const name = "$&$&";                               // user-controlled
"Hello NAME".replace("NAME", name);                // 'Hello NAMENAME'
"Hello NAME".replace("NAME", () => name);          // 'Hello $&$&'

Python. The re.escape docs say it “must not be used for the replacement string in sub() and subn(), only backslashes should be escaped.” In practice, passing a function avoids the problem entirely:

s = "name: NAME"
re.sub("NAME", r"C:\new\1", s)          # re.error: invalid group reference 1 at position 7
re.sub("NAME", lambda m: r"C:\new\1", s)  # 'name: C:\\new\\1'

A replacement string that happens to contain \n or \1 either changes the output or raises, depending on the text. Either is a bug when the text comes from a user. The same caution applies to anything that renders model or user output into templates; see treating LLM output as untrusted input.

SQL LIKE: parameters are not enough

A bind parameter keeps the value out of the SQL grammar, so '; DROP TABLE is just text. But LIKE interprets % (any sequence) and _ (any single character) inside the value, bound or not. The PostgreSQL docs state: “The default escape character is the backslash but a different one can be selected by using the ESCAPE clause.” Writing ESCAPE '' “effectively disables the escape mechanism.”

Escape the escape character first, then the wildcards:

def like_escape(s: str, esc: str = "\\") -> str:
    return s.replace(esc, esc * 2).replace("%", esc + "%").replace("_", esc + "_")

# SQLite: no escape character unless you declare one
cur.execute(
    "SELECT name FROM u WHERE name LIKE ? ESCAPE '\\'",
    ("%" + like_escape(term) + "%",),
)

Test table: alice, bob, 50% off, a_b, axb. Results with the search value bound as a parameter:

Two things stand out. First, a bound % or _ returns every row: that turns a filtered search into an export of the table. Second, the escaping and the ESCAPE clause must agree. SQLite has no default escape character, so escaped input without ESCAPE '\' matched nothing. PostgreSQL uses backslash by default, but stating ESCAPE '\' anyway makes the query portable and removes the dependency on the default.

Two more differences we observed: SQLite’s LIKE was case-insensitive for ASCII ('ALICE' LIKE 'alice' returned 1), while PostgreSQL’s was case-sensitive (false; use ILIKE there). If your ORM offers a “contains” or “starts with” helper, check whether it escapes wildcards for your database before relying on it.

The same applies to other pattern operators: PostgreSQL’s docs warn, “Be wary of accepting regular-expression search patterns from hostile sources”, for SIMILAR TO and POSIX regex operators.

Checklist

• Decide whether the user is supplying text or a pattern. Text gets escaped; patterns need a safe engine and limits.
• Use re.escape, RegExp.escape or regexp.QuoteMeta. Feature-detect RegExp.escape on Node.js 22 and older browsers.
• Never put fallback-escaped text inside [...] or directly after a backslash escape.
• For LIKE: bind the value, escape \, %, _ in that order, and always write ESCAPE '\'.
• Use a function, not a string, when user text is the replacement in replace or re.sub.
• Add a test with ., .*, %, _, $& and a backslash in the input. The bug is invisible with ordinary names.

Limits of this article

We tested the runtimes and versions listed above; MySQL, SQL Server and Oracle have their own LIKE escape rules and were not tested. Other regex dialects (Java, .NET, PCRE) have their own quoting functions not covered here. The JavaScript fallback is shown to illustrate its limits, not as a recommendation.

Sources and verification

In February 2021, security researcher Alex Birsan demonstrated a technique that compromised build systems at Apple, Microsoft, PayPal, Tesla, Uber, Yelp, and more than 30 other major companies — earning over $130,000 in bug bounties in the process. None of it involved a zero-day exploit, stolen credentials, or malware hidden inside a legitimate package. It exploited a single, widely shared assumption in how package managers resolve dependency names.

The assumption being exploited

Many organizations use internal, unscoped package names for private code — something like auth-utils or internal-logger, hosted on a private registry alongside public packages resolved from npm, PyPI, or similar. Several package managers, when configured to check both public and private registries, will resolve to whichever source has the higher version number, or will check the public registry as part of normal resolution regardless of whether a private package with the same name exists. If an attacker publishes a public package with the exact same name as your private one, at a deliberately high version number, some build configurations will pull the attacker’s public package instead of your legitimate internal one — with no error, and no obvious signal that anything went wrong.

How Birsan actually found the names

The hardest part of this attack isn’t the publishing step — it’s knowing what internal package names to target in the first place. Birsan’s research found that internal package names leaked through remarkably mundane channels: package.json files accidentally committed to public repositories, internal package names appearing inside minified JavaScript bundled and shipped to production (since build tools sometimes embed dependency manifests into bundled output), error messages exposing internal paths, and even job postings or forum discussions mentioning internal tooling by name. None of this required any kind of breach — it was all information organizations had, in effect, published themselves without realizing what it enabled.

Why this isn’t caught by normal vulnerability scanning

A dependency confusion package has no known vulnerability associated with it — it’s often a brand-new package with no CVE, no flagged malicious signature, and nothing that would trip a traditional CVE-based scanner. The “vulnerability” isn’t in any package’s code at all; it’s in the resolution logic deciding which package to install. This is why teams that already run vulnerability scanning in CI can still be fully exposed to this attack — the two problems are structurally different, and one doesn’t provide any coverage for the other.

Closing the gap

Scope your private packages using your registry’s namespace/scope feature (npm’s @your-org/package-name scoping, for example) rather than unscoped names — a properly scoped private package doesn’t collide with anything in the public registry’s global namespace, closing the ambiguity the attack depends on.

Explicitly configure your package manager to resolve specific scopes only from your private registry, rather than allowing it to check public sources as a fallback or alongside private ones for anything internal. Most package managers support this configuration (a .npmrc scope-to-registry mapping, for example), and it removes the resolution ambiguity at the source rather than relying on naming conventions alone.

Register placeholder packages for your internal names on public registries, even if they contain nothing but a notice — a defensive squatting move that closes the door on an attacker registering that name later, though this doesn’t scale well as an organization’s internal package count grows and shouldn’t be relied on as the primary defense.

Audit what your internal package names actually are, and whether any have already leaked through the same channels Birsan documented — committed manifest files, bundled minified output, error messages. This audit is worth doing once deliberately, since these leaks tend to be historical accidents rather than ongoing practices, and finding them after the fact still closes future exposure.

Why this attack pattern hasn’t gone away

Once Birsan’s technique became public, hundreds of copycat packages appeared on public registries using names patterned after other companies’ likely internal package naming — some from researchers replicating the technique for further bug bounties, some with less benign intent. The underlying resolution ambiguity in package managers that don’t enforce strict scope-based routing hasn’t been universally fixed at the tooling level, which means the exposure Birsan demonstrated in 2021 remains present in any organization that hasn’t specifically configured against it, regardless of how much time has passed since the original disclosure.

A practical checklist

• Use registry scoping for all internal/private packages, never unscoped names
• Configure your package manager to route specific scopes exclusively to your private registry
• Audit historical leaks of internal package names in committed files, bundled output, and public discussions
• Treat this as a distinct control from vulnerability scanning — one does not provide coverage for the other
• Consider defensive registration of internal package names on public registries as a secondary, not primary, mitigation

If your product lets users type a regular expression (a log search box, an alerting rule, a URL routing rule, a “block messages matching” filter), you have handed them a way to burn your CPU. In a backtracking engine, a short pattern and a short input can keep a thread busy for seconds or years. The fix is not a better regex review process, because you are not the one writing the patterns.

The short answer: run user-supplied patterns on an engine that guarantees linear-time matching (RE2, Go’s regexp, Rust’s regex), cap pattern length, and reject features those engines do not support instead of quietly falling back. If you are stuck with a backtracking engine, run the match somewhere you can kill it on a deadline.

Why a backtracking engine is the problem

Python’s re, JavaScript’s RegExp (V8’s Irregexp) and .NET’s default engine are backtracking engines. When a match fails, they back up and try every other way the pattern could have split the input. For most patterns that is fast. For patterns with nested or overlapping repetition, the number of ways to split the input grows exponentially.

OWASP’s wiki page on ReDoS describes an “evil” regex as one with grouping with repetition where the repeated group contains repetition or overlapping alternation. Its examples include (a+)+, ([a-zA-Z]+)*, (a|aa)+ and (a|a?)+.

We timed the first one in Python 3.13.18 against a string of a characters followed by !, so the match has to fail:

import re, time

pat = re.compile(r'^(a+)+$')
pos = re.compile(r'^(?:a++)+$')   # possessive quantifier, Python 3.11+

for n in (18, 20, 22, 24):
    s = 'a' * n + '!'
    t = time.perf_counter(); pat.match(s); t1 = time.perf_counter() - t
    t = time.perf_counter(); pos.match(s); t2 = time.perf_counter() - t
    print(f"n={n:2d} backtracking={t1:8.4f}s possessive={t2:.6f}s")

n=18 backtracking=  0.0088s possessive=0.000005s
n=20 backtracking=  0.0429s possessive=0.000005s
n=22 backtracking=  0.1680s possessive=0.000003s
n=24 backtracking=  0.5356s possessive=0.000005s

Each additional two characters roughly quadrupled the time. Extrapolate to a 40-character input and one request ties up a worker for hours. Node.js 22 behaves the same way: /^(a+)+$/.test('a'.repeat(24) + '!') took 495 ms in our sandbox.

The possessive rewrite fixes this pattern because a++ refuses to give characters back. That is a valid fix when you write the pattern. It does nothing when a user writes it, because the user will not write the possessive version.

Two different threats

It helps to separate the cases, because the defences differ.

This article is about the second row. The third row is the most common way the second row happens by accident: someone builds new RegExp(userInput) to implement a “contains” search that never needed a regex.

Engines that are built for untrusted patterns

RE2. Google’s RE2 README states the design goal directly: it was built “to handle regular expressions from untrusted users without risk”, and “one of its primary guarantees is that the match time is linear in the length of the input string”. It also says its parser, compiler and execution engines “limit their memory usage by working within a configurable budget”. The price is features: RE2 “does not support constructs for which only backtracking solutions are known to exist”. That means no backreferences and no look-around.

Go’s regexp. The package uses RE2 syntax, and its source documents that the implementation “is guaranteed to run in time linear in the size of the input”.

Rust’s regex crate. Its README says “all regex searches in this crate have worst case O(m * n) time complexity, where m is proportional to the size of the regex and n is proportional to the size of the string being searched”. Its documentation says the crate “also, to a certain extent, supports untrusted patterns”, mainly “by limiting their size by default”, which you can tune with RegexBuilder::size_limit.

Note the m in that complexity. Linear in the input is not the same as free: a huge pattern still costs more to compile and run. That is why a pattern length cap belongs in front of every engine, safe or not.

Engines that say they are not

.NET. Microsoft’s regex best-practices page is unusually direct:

The .NET regular expression engine does not offer protection against untrusted patterns, and applications should not create regular expression patterns from untrusted user-provided values.

It adds that time-out values and RegexOptions.NonBacktracking (introduced in .NET 7, which “guarantees linear-time processing in the length of the input”) “help protect against accidental performance problems in developer-authored patterns. They are not intended as a security boundary against malicious patterns.” Use them for your own patterns, and do not treat them as permission to accept user-written ones.

Ruby. Ruby 3.2 added two ReDoS mitigations, described in the 3.2.0 release notes. A memoization-based matcher completes “most Regexp matching (about 90% in our experiments)” in linear time, at the cost of memory “proportional to the input length”. Because that optimization “cannot be applied to some kind of regular expressions, such as those including advanced features (e.g., back-references or look-around)”, Ruby also added Regexp.timeout, a global setting, and a per-regex timeout: keyword on Regexp.new. Both help. Neither turns Ruby’s engine into one designed for hostile patterns.

Python and JavaScript. Python’s re documentation describes no match timeout. Python 3.11 added possessive quantifiers and atomic groups (?>...), which help you write safer patterns but do nothing about patterns you did not write. JavaScript’s RegExp has no timeout either. V8 has shipped an experimental non-backtracking engine since V8 8.8, behind --enable-experimental-regexp-engine, which adds a non-standard l (“linear”) flag. V8’s own post calls it experimental “because Irregexp is orders of magnitude faster than the new engine on most common patterns”. With the flag on, /^(a+)+$/l failed on a 50,000-character evil input in about 3 ms in our Node.js 22.23 test. Running production on an experimental V8 flag is a decision to make deliberately, not a default.

Accepting patterns also exposes you to bugs in the regex parser and compiler themselves, not just slow matching. Our write-up of GitLab CVE-2026-97229 covers a remote code execution flaw in how GitLab compiled regular expressions from CI/CD configuration. Using a small, heavily fuzzed engine reduces that risk too.

Pattern 1: Python with RE2

This uses the google-re2 package (we tested 1.1.20251105 with Python 3.13). It caps pattern length, compiles with RE2, and turns unsupported syntax into a clear error your API can return as a 400.

import re2

MAX_PATTERN = 256

def compile_user_pattern(pattern: str):
    """Compile a user-supplied pattern with RE2 or raise ValueError."""
    if len(pattern) > MAX_PATTERN:
        raise ValueError("pattern too long")
    try:
        return re2.compile(pattern)
    except re2.error as e:
        raise ValueError(f"unsupported or invalid pattern: {e}") from None

What happened when we ran it:

The same evil pattern that took half a second on 24 characters in re finished a million characters in milliseconds. Two practical notes from the test: RE2 logs parse errors to stderr through its own logging, so expect noise in your logs when users submit bad patterns. And do not catch the error and retry with re. That fallback reopens the exact hole you closed.

Pattern 2: Node.js with a killable worker

If you cannot add a native RE2 binding, isolate the backtracking engine. A worker thread can be terminated mid-match, which a setTimeout on the main thread cannot do: a regex blocks the event loop until it returns. This is tested on Node.js 22.23.4:

// safe_match.mjs: run an untrusted pattern in a worker and kill it after a deadline.
import { Worker } from 'node:worker_threads';

const WORKER_SRC = `
  const { parentPort, workerData } = require('node:worker_threads');
  const { pattern, flags, input } = workerData;
  try {
    parentPort.postMessage({ ok: true, match: new RegExp(pattern, flags).test(input) });
  } catch (e) {
    parentPort.postMessage({ ok: false, error: e.message });
  }
`;

export function safeTest(pattern, input, { flags = '', timeoutMs = 100, maxPattern = 256 } = {}) {
  if (pattern.length > maxPattern) return Promise.resolve({ ok: false, error: 'pattern too long' });
  if (!/^[gimsuy]*$/.test(flags)) return Promise.resolve({ ok: false, error: 'bad flags' });
  return new Promise((resolve) => {
    const w = new Worker(WORKER_SRC, {
      eval: true,
      workerData: { pattern, flags, input },
      resourceLimits: { maxOldGenerationSizeMb: 32 },
    });
    const timer = setTimeout(() => { w.terminate(); resolve({ ok: false, error: 'timeout' }); }, timeoutMs);
    w.once('message', (m) => { clearTimeout(timer); w.terminate(); resolve(m); });
    w.once('error', (e) => { clearTimeout(timer); resolve({ ok: false, error: e.message }); });
  });
}

Results:

• safeTest('^(a+)+$', 'a'.repeat(40) + '!') returned { ok: false, error: 'timeout' } after 103 ms. On the main thread that match would not finish.
• safeTest('^[a-z]+@example\\.com$', 'alice@example.com') returned { ok: true, match: true }.
• safeTest('(unclosed', 'x') returned the syntax error instead of throwing.

The cost: spawning a worker per call averaged 25.4 ms in our sandbox, over 20 calls. That is fine for saving a rule. It is too slow for matching every log line. For high-volume matching, keep a small pool of long-lived workers and replace any worker you have to terminate, or move to an RE2 binding. This is a containment pattern, not a fix: an attacker can still make every match hit the timeout, so rate-limit pattern submissions and count timeouts per user.

A checklist for features that accept patterns

1. Ask whether you need regex at all. Substring, prefix or glob matching covers most “search” features and has no ReDoS surface.
2. Pick a linear-time engine (RE2 or a binding, Go regexp, Rust regex) for any pattern a user can write, including admins and API clients.
3. Cap pattern length and, if you can, the number of patterns per user or rule set.
4. Reject unsupported features with a clear message. Never fall back to a backtracking engine.
5. Cap input length for each match. Linear time on a 2 GB input is still a lot of time. Our post on decompression bombs in Node.js covers the related problem of inputs that grow after you accept them.
6. If you must backtrack, isolate it. Use a worker or process you can kill, a hard deadline, and a memory limit. Ruby’s Regexp.timeout and .NET’s matchTimeout are useful extra layers.
7. Watch for it. Log match timeouts and compile failures by user, and alert on spikes.

Limits of this article

• Timings are from a shared cloud sandbox and will differ on your hardware. The growth rate, not the absolute numbers, is the point.
• We did not test .NET or Ruby directly, and we do not cover Java, PCRE or other engines here. Statements about them come from their documentation, quoted above.
• We tested one Python RE2 binding (google-re2). Node.js RE2 bindings exist, but we did not test one for this article.
• A linear-time engine removes catastrophic backtracking. It does not remove the need for size limits, rate limits or patching the engine itself.

Sources and verification

A modern build pipeline trusts a long chain of things by default, mostly without anyone deciding to trust them explicitly: the package registry resolving your dependencies, the CI runner executing your build steps, every third-party action or plugin pulled into that process, the base image your container starts from. A supply chain attack doesn’t need to compromise your own code at all — it just needs to compromise one link in that chain, because your pipeline will trust whatever that link delivers.

Dependency resolution as an attack surface

Package managers resolve dependencies by name and version, largely trusting that a package’s identity maps to what it claims to be. This assumption is exactly what dependency confusion attacks exploit — publishing a public package under the same name as an internal one, at a higher version number, so the build system pulls the attacker’s code instead of the legitimate internal package. This isn’t a bug in any specific package manager; it’s a structural consequence of how most of them are designed to resolve names across multiple registries.

Typosquatting works on the same trust assumption from a different angle — publishing a malicious package with a name one character off from a popular legitimate one, betting that enough developers will mistype it or copy a typo from a tutorial to make the attack worthwhile at scale.

Build-time script execution

Most package managers support scripts that run automatically during install — npm’s postinstall, for example. This means installing a dependency can execute arbitrary code on the machine running the install, before your application code ever runs, and before any application-level security control has a chance to matter. A compromised or malicious package doesn’t need to be imported and called by your code to do damage; simply being present in node_modules (or the equivalent for your ecosystem) at install time can be enough.

CI/CD runners and third-party actions

CI pipelines commonly pull in third-party actions, plugins, or shared workflow steps maintained outside your organization. Each one runs with whatever permissions and secrets access your pipeline configuration grants it — meaning a compromised or malicious third-party action has the same practical reach as a compromised dependency, but often with direct access to CI secrets (cloud credentials, signing keys, deployment tokens) that application dependencies don’t typically touch. A popular action being compromised at the source — through a maintainer account takeover, for example — propagates instantly to every pipeline that references it, especially ones pinned to a mutable tag rather than a specific commit.

Base images and the layers you didn’t build

A container build starting FROM a public base image inherits everything already baked into that image — and if that base image is compromised upstream, at the registry or at the maintainer level, every image built from it inherits the compromise without any change to your own Dockerfile. This is the same trust-chain problem as dependency resolution, just one layer further removed from your own code.

Why this class of attack is different from a typical vulnerability

A traditional vulnerability is a flaw in code that needs to be found and exploited. A supply chain attack often requires no vulnerability at all — it just requires the attacker to get their code accepted as a trusted input somewhere in the pipeline, at which point it executes with whatever trust and access that input normally receives. This means traditional vulnerability scanning, which looks for known-bad code patterns or known CVEs, often doesn’t catch a well-executed supply chain attack at all, since the malicious package or action may have no publicly known vulnerability associated with it — it’s simply doing something it wasn’t supposed to do, using access it was never denied.

Where this leaves defenses

Pin dependencies and actions to exact versions or commit hashes, not mutable tags — a tag like v2 or latest can silently point to different, potentially compromised code over time, while a pinned commit hash cannot change without the reference itself being updated.

Scope your private package names to a registry that doesn’t allow public namespace collision, or explicitly configure your package manager to only resolve certain scopes from your private registry, closing the specific gap dependency confusion exploits.

Restrict what CI pipeline secrets a given workflow or job actually needs, rather than granting broad access by default — a compromised third-party action in a job with narrowly scoped secrets can do meaningfully less damage than one running with access to everything.

Generate and monitor SBOMs across your build pipeline, not just your application dependencies, so a newly disclosed compromise in a base image or build tool can be checked against your actual exposure quickly.

Supply chain security isn’t a single control — it’s an acknowledgment that your pipeline’s trust boundary extends far beyond your own code, to every registry, runner, action, and base image it depends on, and each one needs to be treated as a real part of your attack surface rather than an assumed-safe utility.

A secure file upload accepts only the types you need, decides the filename and extension itself, stores the bytes somewhere nothing will execute or serve them directly, and checks authorization again on download. The OWASP File Upload Cheat Sheet says it plainly: “There is no silver bullet in validating user content.” No single check is enough, so you stack them.

This guide builds that stack in Node.js and tests it. Versions: Node.js 22.23.4, Express 5.3.0, Multer 2.5.0, file-type 22.3.0 and sharp 0.35.5, installed from npm on 2026-10-30.

Why uploads keep turning into breaches

Unrestricted upload is CWE-434. In the CISA KEV catalog (version 2026.10.29), 24 entries carry CWE-434, eight of them added in 2026. The count is a floor: not every KEV entry has a CWE assigned. The most recent is the Magento “PolyShell” bug we covered in Magento CVE-2026-48356: Patch and Hunt, where the fix included making sure upload directories can’t execute code.

The OWASP cheat sheet groups the risks into two kinds:

• Malicious files: exploits for the parser that processes the file, phishing documents, zip and XML bombs, overwriting existing files, and active content such as HTML or SVG that attacks other users.
• Public retrieval: if uploads are publicly reachable, attackers can enumerate other users’ files, use them for DoS, or host illegal content on your domain.

The endpoint, step by step

Here is the full server. Each control is explained below.

// Node.js 22, Express 5.3.0, Multer 2.5.0, file-type 22.3.0 (package.json: "type": "module")
import express from 'express';
import multer from 'multer';
import { fileTypeFromBuffer } from 'file-type';
import { randomUUID } from 'node:crypto';
import { writeFile, mkdir } from 'node:fs/promises';
import path from 'node:path';

const UPLOAD_DIR = process.env.UPLOAD_DIR ?? '/srv/app-uploads'; // not under any static/public dir
const ALLOWED = new Map([            // detected type -> extension we will store
  ['image/png', 'png'],
  ['image/jpeg', 'jpg'],
  ['application/pdf', 'pdf'],
]);
const files = new Map();             // id -> { owner, mime, ext }; use your database in production

const upload = multer({
  storage: multer.memoryStorage(),   // bytes stay in memory until they pass checks
  limits: { fileSize: 5 * 1024 * 1024, files: 1, fields: 5, parts: 6 },
});

// Stand-in for your real auth middleware
function requireUser(req, res, next) {
  const user = req.get('x-demo-user');
  if (!user) return res.status(401).json({ error: 'login required' });
  req.user = { id: user };
  next();
}

const app = express();

app.post('/uploads', requireUser, upload.single('file'), async (req, res) => {
  if (!req.file) return res.status(400).json({ error: 'no file' });
  const detected = await fileTypeFromBuffer(req.file.buffer);   // magic bytes, not the client's Content-Type
  if (!detected || !ALLOWED.has(detected.mime)) {
    return res.status(415).json({ error: 'file type not allowed' });
  }
  const id = randomUUID();
  const ext = ALLOWED.get(detected.mime);
  await mkdir(UPLOAD_DIR, { recursive: true, mode: 0o700 });
  // Server-chosen name; 'wx' fails instead of overwriting; 0o600 = no execute bit
  await writeFile(path.join(UPLOAD_DIR, `${id}.${ext}`), req.file.buffer, { flag: 'wx', mode: 0o600 });
  files.set(id, { owner: req.user.id, mime: detected.mime, ext });
  res.status(201).json({ id });
});

const UUID = /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/;

app.get('/files/:id', requireUser, (req, res) => {
  const meta = UUID.test(req.params.id) && files.get(req.params.id);
  if (!meta || meta.owner !== req.user.id) return res.status(404).end();  // authz on every download
  res.set({
    'Content-Type': meta.mime,                       // the type we detected, never the client's
    'Content-Disposition': `attachment; filename="${req.params.id}.${meta.ext}"`,
    'X-Content-Type-Options': 'nosniff',
    'Content-Security-Policy': "default-src 'none'; sandbox",
  });
  res.sendFile(`${req.params.id}.${meta.ext}`, { root: UPLOAD_DIR });
});

app.use((err, req, res, next) => {
  if (err instanceof multer.MulterError) {
    const status = err.code === 'LIMIT_FILE_SIZE' ? 413 : 400;
    return res.status(status).json({ error: err.code });
  }
  next(err);
});

app.listen(3000, () => console.log('listening on :3000'));

The x-demo-user header and the in-memory files map exist only so the example runs on its own. Replace them with your session middleware and a database table.

1. Authenticate before parsing, and only on the routes that need it

requireUser runs before upload.single(), so an anonymous request is rejected before Multer reads a byte of the body. Multer’s README warns: “Never add multer as a global middleware since a malicious user could upload files to a route that you didn’t anticipate.” Mount it per route, as above.

2. Set every limit

Multer passes limits straight to busboy, and the defaults in the Multer 2.5.0 README are generous: fileSize, files, parts and fields all default to Infinity. The README also notes that “Limits apply to the whole request; there is no per-file limit.” Set them to what the feature needs. Map LIMIT_FILE_SIZE to 413 and other Multer errors to 400 in your error handler, as the example does.

memoryStorage() holds the whole file in RAM, which is why fileSize matters. For large files, use disk storage into a private temp directory and run the same checks before moving the file into place. If you also accept compressed data, the limit has to apply after decompression; see Node.js decompression bombs.

3. Detect the type from content, against an allowlist

The Content-Type of each part is whatever the client says. OWASP: “it is trivial to spoof.” fileTypeFromBuffer() reads the file’s magic number instead, and we compare the result to a short allowlist of types the feature actually needs.

Know the limits of this check. The file-type readme says detection “is a best-effort hint. It does not guarantee the file is actually of that type or that the file is valid/not malformed.” It also covers only binary formats, “not text-based formats like .txt, .csv, .svg”. If you need text formats, validate them with a real parser.

4. Choose the name and extension yourself

The stored name is a UUID plus the extension mapped from the detected type. The user’s originalname is never used on disk, which removes the whole class of tricks OWASP lists for extensions (.jpg.php, .php%00.jpg, .pHp, .phtml, shell.asp:.jpg) and path traversal in filenames. If you need to show the original name, store it as data in your database and escape it on output.

The wx flag makes writeFile fail if the path exists rather than overwrite it. Mode 0o600 means no execute bit, and your process umask can only make it stricter.

5. Store outside anything that serves or executes files

OWASP ranks storage options in this order: a different host, then outside the webroot, then inside the webroot with write-only permissions. UPLOAD_DIR must not be inside express.static(), your nginx root, or a PHP document root. Private object storage (an S3 bucket with Block Public Access on, served by short-lived signed URLs) satisfies “different host”.

If files have to live under a web server’s document root, also turn off per-directory overrides there. OWASP’s example is Apache AllowOverride None, so an uploaded .htaccess can’t remap .png to the PHP handler. For PHP stacks, our php.ini hardening guide covers the upload-related settings.

6. Serve through a handler with defensive headers

The download route checks ownership on every request. Without that, a guessable or leaked ID becomes an IDOR. It then sets four headers:

Serving user files from a separate domain (for example a dedicated usercontent domain) adds one more layer: active content never runs on the same origin as your session cookies.

What we tested, and what got through

We started the server with UPLOAD_DIR set to a temp directory and sent ten requests with curl:

Both stored files were -rw-------. Test 4 is the one to remember. A PNG with code appended is still a valid PNG, so magic-byte detection passed it. It did no harm because of what came after: the traversal filename was ignored, the stored name ended in .png, the directory isn’t served or interpreted, and downloads go out as attachments with a sandbox CSP. Remove any one of those and the polyglot becomes more dangerous.

Re-encode images when you can

For images, OWASP recommends decoding and re-encoding to strip anything that isn’t pixels. With sharp, metadata is dropped by default (“The default behaviour, when withMetadata is not used, is to strip all metadata”, per its type definitions):

import sharp from 'sharp';
// limitInputPixels guards against decompression-style image bombs; sharp's default is 268402689 pixels
const clean = await sharp(req.file.buffer, { limitInputPixels: 40_000_000 }).png().toBuffer();

Run on the polyglot from test 4, the 97-byte input contained <?php; the 90-byte output did not. OWASP adds a caveat worth keeping: the image library “itself handles untrusted input”, so keep it patched and, for high-volume or high-risk uploads, run processing in a separate worker or sandbox. The file-type readme makes the same point for its own parser, recommending a size limit and “a worker thread with a timeout” for untrusted files.

Checklist

• Authenticate before parsing; mount Multer only on upload routes.
• Set fileSize, files, fields and parts.
• Detect type from content; compare to a short allowlist; reject text formats you can’t parse.
• Generate the stored name and extension; never write originalname to disk.
• Store outside the webroot or in private object storage, without execute permissions.
• Serve via a handler that checks ownership and sets attachment, nosniff and a sandbox CSP.
• Re-encode images; scan or sandbox documents if they will be opened by staff.
• Protect the upload form from CSRF if it uses cookie auth.

Limits of this article

• We tested one stack (Express 5.3.0, Multer 2.5.0). Other frameworks have different defaults; check their docs for limits and filename handling.
• We did not test antivirus scanning or Content Disarm and Reconstruction for Office or PDF files, which OWASP also recommends where applicable.
• The in-memory metadata map and header-based “auth” are placeholders and are not production-ready.

Sources and verification

A decompression bomb is a small compressed payload that expands into far more data than your service expects, enough to exhaust memory or tie up a CPU core. MITRE files it as CWE-409, “Improper Handling of Highly Compressed Data (Data Amplification)”. In Node.js, the defence is to count decompressed bytes and stop at a limit you choose. Node gives you that limit in one place, maxOutputLength on the one-shot zlib functions, and nowhere else. Streams, HTTP clients and custom middleware all need their own cap.

We ran every example below on Node.js 22.23.4. Results for each are in the text.

How big the amplification gets

We compressed 100 MiB (104,857,600 bytes) of zeros with each codec Node ships:

Zeros are the best case for a compressor, and the ratio for real data is far lower. That’s the point: an attacker picks the input. A request-body limit of 1 MB on the wire tells you nothing about the decompressed size.

The one-shot functions: maxOutputLength works

Node’s one-shot functions (zlib.gunzip, zlib.inflate, zlib.brotliDecompress, zlib.zstdDecompress and their *Sync forms) accept maxOutputLength. The zlib docs describe it as an option that “Limits output size when using convenience methods”. The default is buffer.kMaxLength, the largest Buffer Node can allocate, so without it you have no practical limit.

const zlib = require('node:zlib');

const LIMIT = 1024 * 1024; // 1 MiB of decompressed output

function safeGunzip(buf) {
  try {
    return zlib.gunzipSync(buf, { maxOutputLength: LIMIT });
  } catch (err) {
    if (err.code === 'ERR_BUFFER_TOO_LARGE') {
      throw Object.assign(new Error('decompressed payload too large'), { status: 413 });
    }
    throw err; // corrupt input, wrong format, etc.
  }
}

With the 100 MiB bombs from the table, gunzipSync, brotliDecompressSync and zstdDecompressSync all threw RangeError with code ERR_BUFFER_TOO_LARGE and the message “Cannot create a Buffer larger than 1048576 bytes”. The async zlib.gunzip() passed the same error to its callback.

Use the one-shot functions when the whole payload is already in memory and you can name a sensible maximum: a webhook body, a cached blob, a small config file.

Streams: maxOutputLength is ignored

The stream classes accept the same options object, so this looks right:

// Looks safe. Isn't.
zlib.createGunzip({ maxOutputLength: 1024 * 1024 });

In our test, piping the gzip bomb through that stream delivered all 104,857,600 bytes and finished without an error. The option is documented for the convenience methods only, and the stream path doesn’t enforce it. Nothing warns you.

The fix is a Transform that counts bytes after the decompressor and fails the pipeline when the count passes your limit:

const zlib = require('node:zlib');
const { pipeline, Transform } = require('node:stream');

// Fail the pipeline once decompressed output exceeds maxBytes.
function byteLimit(maxBytes) {
  let seen = 0;
  return new Transform({
    transform(chunk, _enc, cb) {
      seen += chunk.length;
      if (seen > maxBytes) {
        const err = new RangeError(`decompressed body exceeds ${maxBytes} bytes`);
        err.code = 'ERR_DECOMPRESSED_TOO_LARGE';
        return cb(err);
      }
      cb(null, chunk);
    },
  });
}

pipeline(
  source,                 // e.g. req, a file stream, an upstream response
  zlib.createGunzip(),
  byteLimit(1024 * 1024),
  destination,
  (err) => { /* err.code === 'ERR_DECOMPRESSED_TOO_LARGE' on a bomb */ },
);

Against the 100 MiB bomb, the pipeline failed with ERR_DECOMPRESSED_TOO_LARGE after exactly 1,048,576 bytes had reached the destination. pipeline() destroys every stream in the chain on error, so the decompressor stops as well.

Two details make this work. The limiter must sit after the decompressor, because counting compressed bytes is the mistake you’re avoiding. And use pipeline(), not chained .pipe() calls, which don’t propagate errors or destroy the upstream streams.

Express: the body parser already counts decompressed bytes

Express’s express.json(), express.urlencoded(), express.text() and express.raw() come from body-parser. Its inflate option defaults to true, and in body-parser 2.4.0 it decodes deflate, gzip, br and, where Node supports it, zstd.

We sent express.json() (default limit of '100kb') a 10 MB JSON body compressed each way:

All three compressed bodies were under 100 KB on the wire and still got 413, so the limit is applied to the decoded body. That’s the behaviour you want. Tested with Express 5.3.0, body-parser 2.4.0 and raw-body 3.0.2.

Two cautions. The body-parser README warns that limits “above the default, for example payloads of 5 MB or more” increase memory use and response times, so raise limit per route, not globally. And if you don’t expect compressed request bodies, inflate: false turns them away with 415 before any decoding.

Custom code is where the gaps are: a handler that does req.pipe(zlib.createGunzip()) for an upload endpoint, or a framework plugin with its own decoder. Give each one the byte limiter above.

fetch(): responses are decompressed with no cap

Node’s built-in fetch() decodes Content-Encoding: gzip for you. We served the 100 MiB gzip bomb from a local server:

• res.headers.get('content-length') returned 101941, the compressed size.
• await res.arrayBuffer() returned 104,857,600 bytes.

There’s no size option on arrayBuffer(), json() or text(). If you fetch URLs you don’t control (webhooks, link previews, feed readers, anything with a user-supplied URL), read the body with a cap:

// Read at most maxBytes of a fetch() response body (after fetch's own decompression).
async function readCapped(res, maxBytes) {
  const reader = res.body.getReader();
  const chunks = [];
  let total = 0;
  for (;;) {
    const { done, value } = await reader.read();
    if (done) break;
    total += value.byteLength;
    if (total > maxBytes) {
      await reader.cancel();
      throw new RangeError(`response exceeds ${maxBytes} bytes`);
    }
    chunks.push(value);
  }
  return Buffer.concat(chunks);
}

const res = await fetch(url, { signal: AbortSignal.timeout(10_000) });
const body = await readCapped(res, 1024 * 1024);

Against the bomb, readCapped(res, 1 MiB) threw “response exceeds 1048576 bytes”. Pair it with a timeout, because a slow trickle is a different attack that a byte cap doesn’t stop. Fetching arbitrary URLs has bigger risks than size, too; our SSRF guide covers the network side.

A checklist for Node services

Also consider:

• Keep the decoder patched. Size limits don’t help against bugs in the decompressor itself. CVE-2026-111497 was an out-of-bounds write in Brotli’s decoder, fixed in Node.js 22.23.4, 24.22.1 and 26.12.1; see our Brotli guide.
• Decide whether you need each codec. zstd arrived in Node.js 22.15.0 and is marked Experimental in the Node 22 docs, yet body-parser 2.4.0 accepts it automatically when the runtime supports it. If clients never send it, inflate: false or a proxy rule removes that path.
• Push the limit to the edge as well. A reverse proxy that decompresses request bodies should cap the decoded size too, so the application isn’t your only control.

Limits of this article

All results come from Node.js 22.23.4 on Linux with Express 5.3.0, body-parser 2.4.0 and raw-body 3.0.2, using 100 MiB of zeros as the bomb. Other Node release lines, frameworks (Fastify, Koa, NestJS adapters) and HTTP clients (axios, undici’s request) may behave differently. Test them the same way. We measured whether limits held, not peak memory use or CPU time.

Sources and verification

To stop session fixation in PHP, call session_regenerate_id(), or the timestamp-based rotation shown below, whenever a user’s privilege changes. Do it before you store the authenticated user in $_SESSION. Don’t destroy the old session on the spot. Mark it with a timestamp and refuse it after a short grace period, and enforce your own idle and absolute timeouts, because PHP’s garbage collector is not a timeout. That is what PHP’s own manual asks for. Below is a helper that follows it, tested against a fixation attack, plus the one shortcut in the manual’s example that brings the attack back if you use it at login.

Every behaviour here was run on PHP 8.3.6 CLI with the built-in web server (php -S) and curl, using the default files save handler. The cookie flags and php.ini settings that go with this code are covered in our php.ini security hardening guide. This article is about the session lifecycle in your application code.

The attack strict mode doesn’t stop

session.use_strict_mode=1 makes PHP reject a session ID it never issued. That stops an attacker inventing an ID such as PHPSESSID=123456. But the PHP manual is explicit about the gap: “an attacker can force users to use an initialized session ID which has been created by an attacker.” The attacker visits your site, receives a real ID, and plants it in the victim’s browser. The manual describes two routes: setting a cookie that the browser’s precedence rules let override yours (for example from another subdomain), and JavaScript injection. If your login code keeps that ID, the attacker now holds an authenticated session.

We reproduced it with a minimal app whose login does only $_SESSION['uid'] = 42;, run with strict mode on:

$ PHPFLAGS="-d session.use_strict_mode=1" ./test.sh naive 8090
attacker ID: pmq468mni64u18nhukmh7vqe1v
logged in
ID after login: unchanged
attacker replays old ID: account page for uid 42

The test script fetches / to get a real ID, sends /login with that ID as the victim, then replays the ID as the attacker.

What PHP’s manual requires

The session security chapter is unusually prescriptive. The rules that matter for application code:

• Rotate on privilege change, before writing auth state. “Session IDs must be regenerated when user privileges are elevated, such as after authenticating. session_regenerate_id must be called prior to setting the authentication information to $_SESSION.” Rotate again on any later privilege change, such as entering an admin area or completing step-up authentication. The OWASP Session Management Cheat Sheet makes the same point: renew the ID “after any privilege level change”.
• Don’t delete active sessions immediately. “session_regenerate_id(true); and session_destroy must never be called together for an active session.” Deleting right away loses sessions when requests overlap or the new cookie never arrives. It also removes your chance to notice that someone used an old ID.
• Use timestamps instead. Set “a short-term expiration time (timestamp) in $_SESSION” on the old session and refuse it later: “a few seconds later for stable networks… and a few minutes later for unstable networks such as cell phones or Wi-Fi.”
• Don’t rely on session.gc_maxlifetime for expiry. “Attackers may access a victim’s session ID periodically to prevent its expiration and keep exploiting it.” The setting only controls when data “will be seen as ‘garbage’ and potentially cleaned up” (default 1440 seconds).
• Treat obsolete-ID access as a signal. When an expired ID is used, the manual recommends removing “authenticated status from all of the user’s sessions” and forcing re-authentication.

The session_regenerate_id() page has two example implementations. Both are labelled “not fully working code, but an example!”

A tested rotation helper

session_guard.php follows the manual’s pattern, with two corrections we found in testing (explained after the code). It targets PHP 8.1 or later (session_create_id() exists from 7.1, and the cookie-options array for setcookie() from 7.3).

<?php
// session_guard.php: timestamp-based session ID rotation, adapted from the
// pattern in the PHP manual's session_regenerate_id() page.
declare(strict_types=1);

defined('SESSION_GRACE')    || define('SESSION_GRACE', 60);     // old ID usable after rotation (s)
defined('SESSION_IDLE')     || define('SESSION_IDLE', 1800);    // idle timeout (s)
defined('SESSION_ABSOLUTE') || define('SESSION_ABSOLUTE', 28800); // absolute timeout (s)
defined('SESSION_ROTATE')   || define('SESSION_ROTATE', 900);   // periodic rotation (s)

final class ObsoleteSessionAccess extends RuntimeException {}

function secure_session_start(): void
{
    ini_set('session.use_strict_mode', '1');
    session_start();
    $now = time();

    // 1. Old ID after rotation: allow a short grace period, then refuse.
    if (isset($_SESSION['destroyed'])) {
        if ($_SESSION['destroyed'] < $now - SESSION_GRACE) {
            throw new ObsoleteSessionAccess('obsolete session ID used');
        }
        if (isset($_SESSION['new_session_id'])) {
            // Cookie for the new ID was probably lost: move the client over.
            session_commit();
            session_id($_SESSION['new_session_id']);
            session_start();
            return;
        }
    }

    // 2. Idle and absolute timeouts, enforced in application code.
    if (isset($_SESSION['uid'])) {
        if ($now - ($_SESSION['last_seen'] ?? 0) > SESSION_IDLE
            || $now - ($_SESSION['created'] ?? 0) > SESSION_ABSOLUTE) {
            secure_logout();
            session_start();
            return;
        }
        $_SESSION['last_seen'] = $now;
        if ($now - ($_SESSION['rotated'] ?? 0) > SESSION_ROTATE) {
            secure_regenerate(true);
        }
    }
}

// $forward: let a client still holding the old ID be moved to the new one
// during the grace period (lost Set-Cookie on a flaky network). Never forward
// on a privilege change: whoever holds the old ID would be handed the new one.
function secure_regenerate(bool $forward): void
{
    $data = $_SESSION;                      // session_start() below loads an empty session
    $new = session_create_id();
    if ($forward) {
        $_SESSION['new_session_id'] = $new;
    }
    $_SESSION['destroyed'] = time();
    session_commit();                       // old session keeps the markers

    session_id($new);
    ini_set('session.use_strict_mode', '0'); // let session_start() accept $new
    session_start();
    ini_set('session.use_strict_mode', '1');
    $_SESSION = $data;
    $_SESSION['rotated'] = time();
}

function secure_login(int $uid): void
{
    secure_regenerate(false);               // rotate BEFORE marking authenticated
    $_SESSION['uid'] = $uid;
    $_SESSION['created'] = $_SESSION['last_seen'] = time();
}

function secure_logout(): void
{
    $_SESSION = [];
    $p = session_get_cookie_params();
    setcookie(session_name(), '', [
        'expires' => time() - 3600, 'path' => $p['path'], 'domain' => $p['domain'],
        'secure' => $p['secure'], 'httponly' => $p['httponly'], 'samesite' => $p['samesite'] ?: 'Lax',
    ]);
    session_destroy();
}

Wire it in by calling secure_session_start() instead of session_start(), secure_login($userId) after you have verified the password and any second factor, and secure_logout() from your logout handler. On ObsoleteSessionAccess, return 401 and log the event.

What we tested

Against the same attack, with the helper in place:

$ ./test.sh guard 8086
attacker ID: jt6upaht8b1i3hcuuk743hivm5
logged in
ID after login: 24qohqtgd4trsgfuov1tjn20nm
attacker replays old ID: anonymous

Periodic rotation, with rotation forced on every request and a 2-second grace period:

$ ./test2.sh
account page for uid 42
login ID 10d0f50p49pto2ocoffotrbsv3 rotated to r4428iae8369vin9533ubpb292
old ID inside grace: account page for uid 42
old ID after grace:  401 obsolete session
logout with current ID: logged out
current ID after logout: anonymous

With a 1-second idle timeout, a request made 3 seconds after login came back anonymous with a new session cookie, and the logged-in session’s file was gone from session.save_path. The pre-login session stayed on disk, marked as destroyed, until garbage collection, as the manual intends.

Correction 1: never forward an old ID after login

The manual’s second example deals with lost cookies: if the old ID comes back during the grace period, it switches the client to the new ID it stored in the old session. That is reasonable for periodic rotation, where the person holding the old ID is almost always the legitimate user. At login it is a hole. The attacker holds the old, pre-login ID, so forwarding hands them the new, authenticated one.

Our first draft forwarded in both cases, and the fixation test failed: the attacker’s replay returned account page for uid 42. The manual hints at this in a comment (“Do not try to set session ID again if you would like to remove authentication flag”). The helper makes it explicit: secure_regenerate(false) at login, secure_regenerate(true) only for timed rotation. The trade-off is that a user whose login response is lost has to log in again.

Correction 2: carry the session data across

In the manual’s example, the new session is started with session_id($new); session_start();. In our test on PHP 8.3.6, that started an empty $_SESSION: the authenticated user vanished on the first periodic rotation. The helper copies the data before committing the old session and restores it after starting the new one. At login this also keeps pre-login state, such as a cart.

Other session rules worth enforcing

• Timeouts. OWASP gives common idle timeouts of “2-5 minutes for high-value applications and 15-30 minutes for low risk applications”. Every session should also have an absolute timeout “regardless of session activity”. The helper’s defaults (30 minutes idle, 8 hours absolute) are examples; set your own.
• Locking. PHP locks session data per request, which attackers can abuse to tie up workers. The manual suggests session_start(['read_and_close' => true]) for requests that only read the session, and session_commit() as soon as you have finished writing.
• Remember-me is not a long session. The manual says not to “use long life session IDs for auto-login”. Use a separate, single-use random token in its own cookie, and replace it each time it is used.
• Track active sessions if you need “log out everywhere” or the manual’s response to obsolete-ID access. PHP doesn’t do this for you. The manual suggests a user-ID-prefixed ID from session_create_id(), which “is vital” to pair with strict mode. Don’t use a confidential value as the prefix.
• Sessions don’t stop CSRF. “Sessions and authentication do not protect against CSRF attacks.” See our CSRF defences comparison.
• Session files are an attack surface. October’s PHP2Shell attempts tried to plant code through session files. See the PHP2Shell patch-and-hunt guide.

Common mistakes

Limits of this article

The helper is a tested example, not a drop-in library. It assumes PHP’s default files handler. A custom or Redis save handler must implement session ID validation for strict mode to work, as the manual notes for user-defined handlers. It does not implement the cross-session “remove authentication from all of the user’s sessions” response, which needs an active-session registry. If you use a framework, prefer its session layer to this helper, and check that it rotates the ID at login and enforces timeouts. Our tests ran on a single PHP process. We did not load-test concurrent requests during rotation.

Sources and verification

A webhook endpoint is a public URL that fulfils an order, grants access or updates a record whenever it receives a correctly shaped POST request. Unlike most of your API, it is designed to accept unsolicited requests from outside, because the sending service decides when to call it. That makes three separate problems worth handling deliberately: forged requests from someone who isn’t the provider, replayed copies of real requests, and duplicate deliveries of the same real event by the provider itself.

Scope. Provider details below come from Stripe’s webhook documentation, GitHub’s “Validating webhook deliveries” and “Best practices for using webhooks” pages, and Shopify’s “Verify webhook deliveries” page, read on October 22, 2026. The Python verification code was run with Python 3.13 against GitHub’s published test vector and against signatures we generated; it was not run against live provider traffic. Providers change their schemes, so check their current documentation before you ship.

Forgery: verify an HMAC signature, on the raw body

Stripe, GitHub and Shopify all sign deliveries with HMAC-SHA256 (hash-based message authentication code using SHA-256). The provider computes an HMAC of the payload with a secret shared with you and sends it in a header; you recompute it and compare. Stripe’s documentation puts the risk plainly: without verification, an attacker could send fake events to trigger actions like fulfilling orders, granting account access or modifying records.

Two implementation details decide whether this works.

Hash the exact bytes you received. Every provider signs the raw body it sent. Stripe lists the ways frameworks break this: adding or removing whitespace, reordering keys, converting the string to JSON, or changing the encoding. In Express, for example, Stripe notes that express.json() applied before the webhook route parses the body first and makes verification fail. Capture the raw body for the webhook route, verify, then parse. When verification fails on real traffic, fix the body capture; don’t weaken the check.

Compare in constant time. GitHub’s documentation says never to use a plain == and to use a constant-time comparison such as crypto.timingSafeEqual (Node.js) or secure_compare (Ruby) to mitigate timing attacks; Stripe says the same. In Python, use hmac.compare_digest.

How the three providers differ

Stripe adds two details worth copying into any verifier: ignore every scheme except v1, which it says prevents downgrade attacks, and accept any one of several v1 signatures, because during a secret rollover (up to 24 hours) Stripe signs with each active secret.

Tested verification code

import base64, hashlib, hmac, time

def _hmac(secret: bytes, msg: bytes) -> bytes:
    return hmac.new(secret, msg, hashlib.sha256).digest()

def verify_github(raw_body: bytes, header: str, secret: bytes) -> bool:
    # X-Hub-Signature-256: "sha256=" + hex digest of the raw body
    expected = "sha256=" + _hmac(secret, raw_body).hex()
    return hmac.compare_digest(expected, header or "")

def verify_shopify(raw_body: bytes, header: str, secret: bytes) -> bool:
    # X-Shopify-Hmac-SHA256: base64 of the HMAC of the raw body
    expected = base64.b64encode(_hmac(secret, raw_body)).decode()
    return hmac.compare_digest(expected, header or "")

def verify_stripe(raw_body: bytes, header: str, secret: bytes,
                  tolerance: int = 300, now: int | None = None) -> bool:
    # Stripe-Signature: "t=<unix time>,v1=<hex>[,v1=...]" over "<t>.<raw body>"
    parts = [p.split("=", 1) for p in (header or "").split(",") if "=" in p]
    ts = next((v for k, v in parts if k == "t"), None)
    sigs = [v for k, v in parts if k == "v1"]          # ignore v0 and others
    if ts is None or not ts.isdigit() or not sigs:
        return False
    expected = _hmac(secret, ts.encode() + b"." + raw_body).hex()
    if not any(hmac.compare_digest(expected, s) for s in sigs):
        return False
    now = int(time.time()) if now is None else now
    return abs(now - int(ts)) <= tolerance

What we checked on October 22, 2026:

For production, prefer the provider’s official library where one exists (Stripe recommends its libraries over manual verification). Code like the above is for providers without one, or for understanding what the library does.

Replay: a valid signature isn’t a fresh request

A signature proves who signed the body, not when the request was sent. An attacker who captures a real delivery can resend it, and the signature still verifies. If the webhook triggers a one-time action, such as a refund or an access grant, that replay does real harm.

The timestamp must be inside what’s signed. Stripe’s documentation explains why it signs timestamp.body: an attacker can’t change the timestamp without invalidating the signature, so a stale request can be rejected. A timestamp sent alongside the signature but not covered by it gives no protection, because an attacker can replace it. Our test above shows the difference: swapping the timestamp broke the signature. If you design your own outgoing webhooks, copy this pattern.

Stripe’s libraries default to a 5-minute tolerance. Stripe warns that a tolerance of 0 disables the recency check entirely, and recommends keeping your clock synchronized with NTP (Network Time Protocol). It also notes that each retry gets a new timestamp and signature, so legitimate retries aren’t rejected as stale.

A time window is not the whole answer. A replay inside the tolerance window still passes. GitHub and Shopify don’t sign a timestamp at all. That is why the next control matters.

Duplicates: process each event once

Providers retry. Stripe says it retries live-mode deliveries for up to three days and that endpoints “might occasionally receive the same event more than once”. Shopify says it retries 8 times over 4 hours after a failure. None of the three promises exactly-once delivery.

The fix is to record the ID of every event you’ve processed and skip ones you’ve seen:

• Stripe: log processed event IDs. Stripe also notes that two separate Event objects can occasionally be generated for the same change; it suggests using the data.object ID together with the event type to spot those. Don’t use the created timestamp to detect duplicates or ordering.
• GitHub: use X-GitHub-Delivery, which GitHub describes as unique per event and recommends specifically against replay attacks. A redelivery you request keeps the same value.
• Shopify: make processing idempotent, or deduplicate on X-Shopify-Webhook-Id. X-Shopify-Event-Id groups deliveries caused by the same merchant action, which matters if you have several subscriptions to one topic.

Recording the ID and performing the action should succeed or fail together, for example in one database transaction with a unique constraint on the event ID. Otherwise a crash between the two can lose or double-process an event.

This one control handles three cases at once: provider retries, redeliveries, and replays that slip inside the timestamp window.

IP allowlisting: an extra layer, not a primary control

Stripe publishes the IP addresses it sends webhooks from and recommends allowlisting them alongside signature verification. GitHub publishes its webhook source addresses through its GET /meta API and notes that they change occasionally, so the allow list needs regular updates. An allow list doesn’t depend on your application code being right, which is its value. It doesn’t help if the address list is stale, if a provider doesn’t publish one, or if the attacker is sending through the provider’s own infrastructure, so keep signature verification as the primary check.

Operational details that matter

• Respond fast, process later. GitHub treats a delivery as failed if you don’t respond with a 2xx within 10 seconds (on GitHub.com), and Stripe says to return 2xx before complex logic. Verify, record the event, queue the work, then respond.
• Reject on any failed check. Do no partial processing. Log which check failed, the source IP and the delivery ID, but avoid logging full payloads that may contain personal or payment data. Repeated failures from one source are worth an alert.
• Exempt only the webhook route from CSRF checks. Stripe notes that frameworks such as Rails and Django may require a CSRF token on every POST and block webhooks; scope the exemption to the webhook route, which is protected by its signature instead. See our CSRF protection guide for why the rest of the app should keep it.
• Rotate secrets. Stripe recommends rolling signing secrets periodically or when you suspect exposure, and supports an overlap of up to 24 hours. Store webhook secrets like any other credential; our guide on detecting and rotating leaked API keys covers the process.
• Only subscribe to events you handle. Stripe recommends it, and it shrinks the set of actions a forged or replayed event could trigger.

Checklist

• Capture the raw body for the webhook route and verify before parsing.
• Use the provider’s exact scheme: header, encoding, signed string, accepted versions.
• Compare signatures in constant time.
• Where a timestamp is signed, enforce a tolerance of a few minutes, never zero, and keep clocks in sync.
• Record processed event or delivery IDs atomically with the action, and skip duplicates.
• Treat IP allowlists as defense in depth.
• Respond quickly; process asynchronously.
• Reject and log failures; alert on repeats.

Webhook receivers are one entry in a wider API surface; our public REST API checklist covers the rest.

About this article

This guide combines two earlier FirewallSync articles on webhook security, published October 18 and 19, 2026, into one updated reference. The October 18 URL now redirects here. We added provider documentation references, a provider comparison and tested code.

Sources and verification

Checked on October 22, 2026.

An insecure direct object reference happens when an application uses a value the user can see or guess — an order number, a document ID, a user ID in a URL — to look up a resource, without separately checking whether the requesting user is actually authorized to access that specific resource. It’s conceptually simple, which is exactly why it’s easy to miss: the request doesn’t fail, doesn’t throw an error, and doesn’t look different from a legitimate one. It just returns data belonging to someone else.

Why standard testing misses it

Functional testing confirms a feature works for the user it was built for. Security testing that stops at authentication confirms a user can log in and reach the feature at all. Neither one, by default, asks “what happens if this same authenticated user changes the ID in the request to something that belongs to someone else” — which is the entire test that actually catches IDOR. It has to be added deliberately as its own test category, per endpoint that accepts an identifier, rather than assumed to be covered by general functional or auth testing.

How to actually test for it

The direct method: authenticate as two different test accounts, and for every endpoint that accepts a resource identifier, attempt to access account A’s resources while authenticated as account B. If the request succeeds and returns account A’s data, that endpoint is vulnerable. This needs to be done systematically across every endpoint that takes an ID — read endpoints, update endpoints, and delete endpoints separately, since an application can correctly restrict reads while still allowing an unauthorized update or delete through the same missing check.

Pay particular attention to endpoints that were added later, or that support secondary features (exports, attachments, comments, activity logs tied to a parent resource) — these are common blind spots because they weren’t part of the original access-control design review, if one happened at all.

Sequential IDs make exploitation trivial, but aren’t the root cause

Switching from sequential numeric IDs to UUIDs is a common recommendation, and it does raise the bar for casual exploitation — an attacker can’t simply increment a number to enumerate other users’ resources. But this is obfuscation, not a fix. If the authorization check is still missing, a UUID-based system is still vulnerable to anyone who obtains a valid UUID through another channel (a shared link, a referrer header, a leaked log entry, or simple correlation from other exposed data). Treat ID format as a hardening measure that raises exploitation cost, not as the actual control that closes the vulnerability.

The actual fix: authorize the object, not just the request

Every code path that fetches a resource by ID needs to verify, as an explicit step, that the currently authenticated user has a legitimate relationship to that specific resource — they own it, it was shared with them, or their role grants access to it — before returning or modifying it. This check has to happen server-side, on every request, independent of anything the client sends about what it thinks it’s allowed to do.

A useful pattern is to make this check structurally hard to skip: instead of writing “fetch the resource, then check authorization” as two separate steps a developer could forget to pair, write data-access functions that require the authenticated user’s identity as an input and only ever return resources that user is authorized for — moving the check into the data layer itself rather than leaving it to be remembered in every route handler.

A practical checklist

• Test every ID-accepting endpoint with a second account’s credentials against the first account’s resources, across read, update, and delete separately
• Don’t treat UUIDs as a fix — they raise exploitation difficulty, not close the gap
• Add explicit object-level authorization at the data-access layer, not scattered per-route
• Specifically review secondary and recently-added endpoints, since these are the most common places the check gets missed
• Include authorization testing as its own category in your test suite, not folded into general functional testing

IDOR is one of the few vulnerability classes where the fix isn’t more complex code — it’s one consistent check, applied everywhere it needs to be, instead of assumed to already be there.

Broken access control has held the top position in the OWASP Top 10 since the 2021 edition, and it’s the category with the most reported occurrences in OWASP’s own contributed testing data — over 318,000 recorded instances across the applications analyzed. That volume isn’t because it’s one specific bug pattern; it’s because “broken access control” covers several distinct ways authorization checks fail, each common enough on its own to matter.

Insecure direct object references (IDOR)

The most familiar pattern: an application exposes a reference to an internal object — an order ID, a document ID, a user ID — directly in a URL or request parameter, and fails to verify that the requesting user is actually authorized to access that specific object. Changing /invoices/1024 to /invoices/1025 and getting another customer’s invoice back is the canonical example. This happens because authentication (confirming who’s logged in) gets implemented and tested thoroughly, while object-level authorization (confirming that specific logged-in user is allowed to see that specific object) gets assumed rather than explicitly checked on every request.

Missing function-level access control

Distinct from IDOR: this is when an application correctly restricts what’s shown in the UI for a given role, but doesn’t enforce the same restriction on the backend endpoint itself. A standard user who can’t see an admin panel in the interface can often still call the admin API endpoint directly if the endpoint itself doesn’t independently verify the caller’s role — the UI hid the button, but nothing stopped the request. Any access control decision made only in frontend code is not actually an access control decision.

Privilege escalation, vertical and horizontal

Vertical escalation is a standard user gaining admin-level capability — often through the function-level gap above, or through a parameter that controls role or permission level and isn’t validated server-side (a request body that includes "role": "admin" and gets trusted rather than ignored). Horizontal escalation is accessing another user’s data at the same privilege level — which is effectively IDOR viewed through a different lens, since both involve one user reaching resources that belong to another.

CORS misconfiguration as an access control failure

A permissive CORS policy — particularly one that reflects an arbitrary request origin back as trusted, combined with credentialed requests — effectively extends your access control boundary to any site that can get a victim to load it, since the browser will now let that third-party origin make authenticated requests on the victim’s behalf. This is access control failing at the browser trust boundary rather than the server logic, but it belongs in the same category because the end result is the same: someone accessing something they shouldn’t.

Why this keeps happening

Authentication has mature, well-tested standard patterns that most frameworks handle reasonably well by default. Object and function-level authorization is inherently application-specific — the framework can’t know on its own whether the currently authenticated user should be allowed to see order #1025, because that depends entirely on your data model and business logic. This means authorization checks have to be deliberately written for each resource type and each endpoint, and any one that’s missed is a gap, not a framework misconfiguration you can patch centrally.

How to actually prevent it

Deny by default, allow explicitly. Every endpoint and every resource access should require an explicit authorization check to succeed, rather than being open unless something blocks it. This flips the failure mode from “silently overexposed” to “loudly broken,” which is far easier to catch in testing.

Enforce authorization server-side, every time, regardless of what the client already checked. Never trust a client-supplied value (a role field, a permission flag) without independently verifying it against the actual authenticated identity’s real permissions on the server.

Test authorization explicitly, not just authentication. A test suite that confirms “unauthenticated users are rejected” but never confirms “user A cannot access user B’s resources” is testing less than half of what actually matters here. Include this as its own category of test, per resource type, not an afterthought bundled into general functional testing.

Centralize authorization logic where possible. Scattering ad hoc permission checks across individual route handlers makes it easy for one to be forgotten. A centralized authorization layer or middleware that every request passes through, with each route declaring what it requires, reduces how many places the check has to be independently remembered and correctly implemented.

Broken access control isn’t a single vulnerability to patch. It’s a category that requires deliberate, per-resource enforcement — which is exactly why it remains the most common category in real-world findings even after years at the top of the list.

Rate limiting is often treated as a solved problem the moment it’s implemented — a number is picked, a library is wired in, and the box gets checked. In practice, the algorithm behind that limit and the scope it’s applied at determine whether it actually stops abuse or just adds latency to legitimate traffic while doing little against a determined attacker.

Fixed window: simple, and exploitable at the boundary

The simplest approach counts requests in a fixed time window — for example, 100 requests per minute, reset every minute on the clock. It’s cheap to implement and reason about, but it has a well-known edge-case flaw: a client can send 100 requests in the last second of one window and another 100 in the first second of the next, achieving 200 requests in roughly two seconds while technically staying within the stated limit for each window. For any rate limit meant to actually cap burst behavior, this boundary effect matters.

Sliding window: closes the boundary gap, costs more to compute

A sliding window log or sliding window counter evaluates the limit over a continuously moving time range rather than discrete fixed buckets, which removes the boundary exploit. The tradeoff is implementation cost — a true sliding log requires tracking individual request timestamps (or an approximation of them), which is more expensive to store and compute at scale than a simple fixed counter, especially across a distributed system where the limit needs to be enforced consistently across multiple servers.

Token bucket: the common choice for allowing controlled bursts

A token bucket algorithm fills a bucket with tokens at a steady rate, and each request consumes one token; if the bucket is empty, the request is rejected or delayed. This naturally allows short bursts (as long as tokens have accumulated) while still enforcing an average rate over time, which better matches how real client traffic behaves — mostly steady, with occasional legitimate spikes — compared to a hard fixed-window cutoff. It’s the algorithm most production API gateways default to for this reason.

The scope you apply it at matters as much as the algorithm

A global rate limit — capping total requests to an endpoint regardless of caller — protects your infrastructure from being overwhelmed, but does nothing to stop one abusive client from degrading service for every other legitimate caller sharing that same limit. Per-identity (authenticated user or API key) or per-IP limiting contains the impact of abuse to the specific source causing it, which is almost always the intent when rate limiting is framed as a security control rather than purely a capacity control.

The two aren’t mutually exclusive — a global ceiling protects infrastructure, and a per-identity limit protects fairness and contains abuse, and most production systems need both layered together rather than picking one.

Where rate limiting fails even when correctly implemented

Distributed attacks split under the limit. An attacker using many IP addresses or many low-volume accounts can stay under a per-identity or per-IP limit while still generating meaningful aggregate load or completing a credential-stuffing campaign slowly enough to avoid triggering any single bucket’s threshold. Rate limiting alone doesn’t solve this — it needs to be paired with anomaly detection that looks at aggregate patterns across identities, not just individual limits.

Expensive endpoints need lower limits than uniform ones provide. A rate limit set uniformly across an entire API treats a cheap read endpoint the same as a computationally expensive report-generation endpoint, meaning the “safe” uniform limit for the expensive endpoint is often still high enough to cause real resource exhaustion. Limits should reflect the actual cost of the operation, not just be copied across endpoints for consistency.

Legitimate retries can look like abuse, and vice versa. A client retrying after a transient failure, without backoff, can trip the same limit as an actual attacker, while a well-behaved distributed attack can stay just under it. Rate limiting is a blunt instrument for distinguishing intent — it should be one layer in a broader strategy that includes authentication, anomaly detection, and endpoint-specific cost awareness, not the sole control standing between an API and abuse.

A practical approach

• Use token bucket (or a sliding window if implementation cost allows) rather than fixed window, if burst behavior and boundary exploitation matter for your traffic
• Apply limits both globally (infrastructure protection) and per-identity (abuse containment) rather than choosing one
• Set limits per-endpoint based on actual computational cost, not a single number applied uniformly
• Treat rate limiting as one layer, not the whole strategy — pair it with monitoring for distributed patterns that individually stay under any single limit

API misconfigurations rarely come from a missing security feature. They come from a default that was fine during prototyping and never got revisited once the API left that stage and started handling real traffic. These are the ones that show up most often in production audits.

Verbose error messages leaking implementation detail

A stack trace or a raw database error returned in an API response is convenient during development and a reconnaissance gift in production — it can reveal database structure, internal file paths, library versions, and sometimes even query fragments that hint at how authorization is implemented. Fix: catch exceptions at the API boundary and return generic error responses to the client, while logging the full detail server-side where it’s actually useful.

CORS configured with a wildcard that shouldn’t be there

Access-Control-Allow-Origin: * combined with credentialed requests is a common and dangerous misconfiguration — though browsers block this specific combination by spec, teams often work around it in ways that reintroduce the risk, such as dynamically reflecting whatever Origin header the request sends back as an allowed origin. That pattern effectively disables the same-origin protection CORS exists to provide. Fix: maintain an explicit allowlist of trusted origins rather than reflecting the request’s own origin back as valid.

Debug or admin endpoints left reachable in production

Endpoints added for local debugging — a /debug, /admin, /internal, or framework-default status page — frequently ship to production because they were never explicitly gated behind an environment check. These often expose configuration values, internal routing information, or unauthenticated administrative actions. Fix: gate anything not meant for public use behind environment-specific configuration, and treat any endpoint reachable without authentication as something that needs an explicit justification, not a default.

Missing or misconfigured security headers

Headers like Strict-Transport-Security, X-Content-Type-Options, and a sensible Content-Security-Policy are cheap to set and commonly skipped on API responses specifically, because teams associate them with browser-rendered pages rather than JSON endpoints — even though many APIs are consumed by browser-based clients that benefit from them. Fix: apply a consistent security header baseline at the gateway or middleware level so it isn’t something each new endpoint has to remember individually.

Default credentials or default configuration left unchanged

Databases, caches, and internal services that back an API frequently ship with default credentials or open-by-default network configuration, and these get exposed when the API sits in front of infrastructure that was configured quickly and never hardened afterward. Fix: treat default credentials as a deployment blocker, not a post-launch cleanup item, and audit backing infrastructure specifically for anything still running default configuration.

Overly permissive HTTP method support

An endpoint built to handle GET requests that also silently accepts PUT, DELETE, or PATCH because the framework’s routing defaults allow it — without anyone deliberately deciding those methods should be supported — creates unintended write or delete paths that were never designed or reviewed. Fix: explicitly declare which HTTP methods each endpoint supports and reject the rest, rather than relying on the framework’s default permissiveness.

Inconsistent authentication enforcement across the API surface

A common pattern in APIs that grow organically: authentication is enforced on primary endpoints but missed on newer, secondary, or auto-generated ones — an admin-added endpoint for a reporting feature, a webhook receiver, an internal utility route. Fix: enforce authentication centrally, as a default every route must explicitly opt out of, rather than something each route has to remember to opt into.

Why these accumulate

Every one of these starts as a reasonable shortcut at some point in development — a permissive CORS setting to unblock local frontend testing, a debug endpoint to speed up troubleshooting, verbose errors to make development faster. None of them are wrong choices during prototyping. They become misconfigurations specifically because nobody owns the step of reverting them before the API is exposed publicly, which is why a pre-launch (and periodic post-launch) configuration review, treated as its own explicit step, catches most of this list before it becomes an incident.

Signing a container image with cosign, the command-line client of the open-source Sigstore project, is a one-line command. Whether the signature protects anyone depends on the other end: the verifier has to say who must have signed the image and which identity provider must have vouched for them. This article walks through keyless signing in a GitHub Actions job, what to pin when verifying, and why an August 2026 advisory about cosign’s own verification is a good reminder that the verifier is part of your trust chain.

We read the Sigstore documentation, the cosign command reference, the sigstore/cosign-installer README, GitHub’s documentation on its OIDC tokens, the cosign release notes and the cosign security advisory on October 13, 2026. We did not run any of the commands for this article, so it is research-based explanation, not hands-on testing. Placeholders in angle brackets are for you to fill in.

The short answer

• Sign: cosign sign <image>@<digest> in your release job. In keyless mode no key pair is stored: cosign gets a short-lived certificate for the job’s OIDC identity.
• Verify: run cosign verify with --certificate-identity and --certificate-oidc-issuer set to the identity and issuer you expect, in the place where images are deployed or pulled.
• Keep cosign patched on both signing and verifying machines. The advisory below shows verification code can itself have bugs.

What keyless signing does

Per the Sigstore cosign documentation, keyless signing “associates identities, rather than keys, with an artifact signature.” Cosign uses an ephemeral key; the page notes the private key is destroyed shortly after signing. Fulcio, Sigstore’s certificate authority, “issues short-lived certificates binding an ephemeral key to an OpenID Connect identity.” The signing event is logged in Rekor, a signature transparency log, “providing an auditable record.” Our article on SLSA build levels and provenance describes the same flow in the context of attestations.

In an automated environment cosign can take an OIDC token directly via --identity-token; the documentation says the token’s audiences claim must contain sigstore. In GitHub Actions, the cosign installer’s example relies on the job’s GitHub OIDC token instead.

Signing in GitHub Actions

The sigstore/cosign-installer README provides an example workflow. The elements that matter for security are:

• Permissions. The job needs id-token: write (annotated in the example as “needed for signing the images with GitHub OIDC Token”). GitHub’s OIDC documentation states that without id-token: write the OIDC JWT ID token cannot be requested. The example also grants packages: write for pushing to ghcr.io and contents: read.
• Sign by digest. The example builds and pushes the image, takes the digest from the build step’s output and signs tag@digest references. We read this as the reason the digest matters: a tag can later be re-pointed to a different image, while a digest identifies specific content. (The cosign signing page we read does not itself state a digest recommendation; this is our reading of the example.)
• No secret for keyless. The README’s keyless step runs cosign sign --yes ${images} with no key. Its other example signs with a key held in repository secrets, which brings back the problem of protecting a long-lived key.
• Untrusted values in shell. The example passes values through environment variables rather than inline expressions, following GitHub’s guidance on script injection.
• Pin the installer. The README says the cosign-release input pins a specific cosign version and that you then maintain that version yourself. Pinning also applies to the installer action: the example references sigstore/cosign-installer@v4.1.0; for stronger protection against a moved tag you can pin actions to a full commit SHA (our suggestion, not from the README).

The signature is stored with the image in the registry. The signing documentation says signatures use the OCI 1.1 referrer specification, and cosign tree <image> shows what is attached. Your registry must support what cosign pushes; we did not test registry compatibility.

Verifying: pin the identity and the issuer

This is the step that turns a signature into a control. For keyless signatures, the cosign command reference says the identity flags are mandatory:

cosign verify <registry>/<repo>@<digest> \
  --certificate-identity=<expected signer identity> \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com

What each flag means, per the reference:

Exact vs regexp. The regexp variants accept Go regular expressions. A loose pattern (for example one that matches any repository in an organization, or any branch) widens who can satisfy your policy. Prefer exact values where you can; if you must use a pattern, anchor it. This is our recommendation.

What identity string to expect. We did not verify, from the sources above, the exact format of the identity that appears in a certificate issued to a GitHub Actions job, so we do not state one here. GitHub’s OIDC documentation defines claims in the token (for example the sub claim, formatted like repo:ORG/REPO:ref:refs/heads/BRANCH in its examples, and job_workflow_ref for reusable workflows), but how those claims map into the Fulcio certificate identity is not something we confirmed. A reasonable procedure (our suggestion): sign a test image from your real release workflow, inspect the certificate on that signature, record the identity and issuer you see there, and then pin those exact values.

What a passing check tells you. That the image content matches the signed digest and that a signer with the pinned identity signed it, with the signing recorded in the transparency log. It does not tell you the image is free of vulnerabilities or malicious code, or that the workflow that signed it was itself uncompromised. For vulnerability status, see our articles on VEX statements and what container image scanning still misses.

Where to run it: at the point of consumption, such as a deploy job or an admission step in your cluster, failing the deployment on mismatch. The cosign reference documents the command-line flags; we did not review Kubernetes admission tooling, so that part is outside this article.

A reminder that the verifier needs patching too

On August 6, 2026, the cosign project published advisory GHSA-fx35-mq7g-6g98, “Verification bypass via public key in legacy bundle.” The facts as stated in the advisory:

What this means for container image signing. The advisory says OCI image verification is not affected, so a pipeline that only runs cosign verify on images in a registry is outside the described bug. It matters if you also sign and verify blobs, such as release binaries, tarballs or SBOM files, using separate bundle files. The general lesson is practical: identity pinning only helps if the verifier actually enforces it, so track cosign releases on every machine that verifies. The cosign releases page lists v3.1.3 and v2.6.5 as the August 6, 2026 releases that carry the fix. The same page records a bundle-format change in the 2.6 line: its notes say the default for signing is now the bundle format, and that --new-bundle-format=false signs in the old format; verification in 3.1.x accepts both formats. Check the release notes for your version before changing flags.

A rollout checklist (our suggestion)

1. Sign only release images from a protected workflow, by digest.
2. Give the signing job only the permissions it needs: id-token: write, plus whatever the registry push requires.
3. Sign a test image, inspect the certificate, and record the exact identity and issuer to pin.
4. Verify wherever the image is deployed, with exact identity and issuer flags, and fail closed.
5. Pin and update cosign deliberately on signing and verifying hosts; subscribe to the project’s security advisories.
6. If you also use blob signatures, confirm none depend on legacy JSON bundles on affected versions.
7. Remember what signing does not cover: see our SBOM minimum-elements article for the inventory side.

Limits of this article

We did not run cosign, sign or verify anything, or test any registry. The cosign command reference we cite is the main branch of the project’s repository, which may differ from the version you run; the Sigstore signing page we read did not discuss differences between cosign v2 and v3. We did not confirm the exact certificate-identity format for GitHub Actions jobs, did not review the Sigstore Public Good Instance’s operational policies or Kubernetes admission tooling, and did not independently re-score the advisory’s CVSS vector.

Sources and verification

Checked on October 13, 2026.

Most public API incidents don’t trace back to a sophisticated or novel technique. They trace back to a well-known control — rate limiting, object-level authorization, input validation — that got deprioritized before launch and never circled back to. This is a checklist of the controls that actually matter, ordered roughly by how often skipping them causes real incidents.

Authentication and object-level authorization

Authenticating a request confirms who’s calling. It says nothing about whether that caller should be allowed to access the specific resource they’re requesting. Broken object-level authorization — where an authenticated user can access another user’s data by changing an ID in the request — remains one of the most common and most exploited API vulnerabilities, precisely because authentication is easy to test and access control on individual resources is easy to forget on any endpoint that wasn’t the main focus during development.

Every endpoint that accepts a resource identifier needs an explicit check that the authenticated caller is actually authorized for that specific resource, not just authenticated in general. This has to be enforced server-side, on every request — never assume that because a UI doesn’t expose a way to request another user’s data, an API consumer can’t construct that request directly.

Rate limiting, applied per-identity and per-endpoint

An API without rate limiting is vulnerable to brute-force credential attacks, scraping, and simple resource exhaustion, regardless of how solid the rest of the security posture is. Rate limits need to be scoped per authenticated identity (or per IP for unauthenticated endpoints), not globally — a global limit lets one abusive client degrade service for everyone else, while a per-identity limit contains the damage to that one caller.

Endpoints that are inherently more sensitive — login, password reset, any action that’s expensive to compute or has real-world side effects — deserve tighter limits than general read endpoints, rather than one uniform rate limit applied everywhere.

Input validation on every parameter, not just the obvious ones

Validate types, formats, and ranges server-side for every input, including ones that feel like internal implementation details — pagination parameters, sort fields, filter values. These are frequently the fields that get skipped because they don’t look security-sensitive, and they’re also where injection and denial-of-service issues (an attacker requesting an enormous page size, or a sort field that maps directly to an unvalidated database column) commonly show up.

Reject unexpected fields rather than silently ignoring them — an API that quietly accepts and processes fields outside its documented schema makes it harder to reason about what the actual attack surface is.

Don’t expose more data than the response needs

A common pattern that causes quiet data exposure: returning an entire internal object or database row because it was convenient, rather than an explicitly defined response schema. This routinely leaks internal fields — hashed passwords, internal flags, other users’ identifiers embedded in nested objects — that were never meant to be public, simply because nobody defined what should and shouldn’t be in the response.

TLS, and actually enforcing it

HTTPS-only sounds obvious, but “supports HTTPS” and “rejects plaintext HTTP entirely” are different configurations, and it’s common for an API to accept both silently, quietly downgrading security for any client (or misconfigured integration) that happens to connect over HTTP. Enforce it at the load balancer or gateway level, not as an assumption about how clients will behave.

Logging and monitoring built for incident response, not just uptime

Standard uptime and error-rate monitoring won’t catch a slow, low-and-slow scraping attack or a credential-stuffing campaign hiding inside otherwise-normal traffic patterns. Log enough detail — caller identity, endpoint, response code, timestamp — to reconstruct what happened during an investigation, and specifically monitor for patterns like unusual volumes of authorization failures or an unusual spread of resource IDs being requested by a single identity.

The checklist

• Object-level authorization enforced server-side on every resource-accessing endpoint, not just authentication
• Rate limits scoped per identity and tightened further on sensitive endpoints
• Server-side validation on every input parameter, including pagination, sorting, and filtering fields
• Explicit response schemas, never raw internal objects
• HTTPS enforced, not just supported
• Logging detailed enough to reconstruct an incident after the fact

None of these are exotic. They’re the controls that get cut when a launch deadline is tight, on the assumption they can be added later — and “later” is usually after the first incident that specifically exploited whichever one got skipped.

SLSA, pronounced “salsa” and short for Supply-chain Levels for Software Artifacts, is a framework for describing how much you can trust the way a software artifact was built. A SLSA Build level (L1, L2 or L3) is a statement about the build platform and the provenance it produces: a signed record of what was built, from what inputs, by which builder. It is not a statement that the software is free of bugs or backdoors. This article explains what each level means, how Sigstore signing and GitHub artifact attestations produce provenance, and what a consumer has to check for any of it to matter.

We read the SLSA specification pages (v1.2 and the retired v1.1), the Sigstore overview, GitHub’s attestation documentation and the GitHub CLI manual on October 12, 2026. We did not build or sign any artifacts for this article; it is research-based explanation, not hands-on testing.

The short answer

• Build L1: provenance exists. It records how the package was built, but the specification says it “can be used to prevent mistakes but is trivial to bypass or forge.”
• Build L2: the build runs on a hosted platform that generates and signs the provenance. This addresses tampering after the build. Forging the provenance requires an explicit attack, which the specification notes may still be easy.
• Build L3: the platform is hardened so that runs cannot influence one another and the signing secret is unreachable from user-defined build steps. This addresses tampering during the build.

Source: SLSA v1.2, Build track basics.

What “provenance” contains

Provenance is a document (in SLSA’s case an attestation, a signed statement about an artifact) linking an artifact’s cryptographic digest to a description of how it was built. The SLSA provenance format uses the predicate type https://slsa.dev/provenance/v1. For Build L1, the specification requires the following fields:

Optional fields include resolvedDependencies (for example, the exact git commit a repository reference resolved to), internalParameters set by the platform, and run metadata such as start and finish times. These field requirements are from the v1.1 provenance page; that page is marked retired in favour of v1.2, and the v1.2 pages we read did not mention changes to the provenance format.

Why the levels differ

The levels are not about better paperwork. Each answers a different attacker.

Level descriptions are from the SLSA v1.2 build track basics and build requirements. The “does not stop” column is our reading of what each level’s requirements leave out; the specification itself defines the levels by what they require. The L3 requirements include that it “MUST NOT be possible for one build to persist or influence the build environment of a subsequent build,” and that provenance be “strongly resistant to forgery by tenants.”

What changed in SLSA v1.2

SLSA v1.0 removed source-code requirements to focus on the Build track. According to the v1.2 “What’s new” page, v1.2 adds a Source track that helps organizations secure their source development process, updates the threat model, and reorganizes the specification to support multiple tracks. The page gives no release date. This article covers the Build track only; we did not review the Source track requirements. The v1.1 pages are marked “Retired” and point to v1.2 as current.

How Sigstore produces the signature

Sigstore is an open project for signing and verifying software. In its keyless flow, according to the Sigstore overview:

1. Cosign, the client, generates a new key pair.
2. It sends the public key and an OpenID Connect (OIDC) identity token to Fulcio, the certificate authority.
3. Fulcio checks the token and issues a short-lived certificate binding the identity to the public key. (The page does not give a lifetime.)
4. Cosign signs the artifact, then discards the private key.
5. The artifact digest, signature and certificate are recorded in Rekor, an append-only transparency log.
6. A verifier checks the signature, confirms the certificate’s identity is the one it expects, validates the certificate against Sigstore’s root of trust, and verifies Rekor’s proof of inclusion.

For CI signing, the identity in the certificate can describe the workflow rather than a person. The practical point: no long-lived signing key exists to steal, but the signature is only meaningful if the verifier decides which identity is acceptable.

GitHub artifact attestations and the SLSA level

GitHub’s documentation says artifact attestations are signed claims about where and how software was built, including links to the workflow, repository, organization, environment, commit SHA and triggering event, and that they can include an SBOM. It states:

• Attestations alone provide SLSA v1.0 Build Level 2. Build Level 3 requires builds to run in a reusable workflow shared across repositories, which isolates the build from the calling workflow.
• Public repositories use the Sigstore Public Good Instance, with the bundle written to a publicly readable transparency log. Private repositories use GitHub’s own Sigstore instance, with no transparency log, federating only with GitHub Actions.
• Attestations are not a guarantee that an artifact is secure; you still need to define and evaluate a policy.
• Sign released software people will run or download, not frequent test builds or individual source files.

Note the version: GitHub’s page refers to SLSA v1.0 levels. We did not check whether GitHub has published a mapping to v1.2.

Verifying: the step most teams skip

Provenance nobody checks protects nobody. The GitHub CLI’s gh attestation verify takes an artifact and requires at least one of --owner or --repo; the manual says that “the more precisely you specify the actor’s identity, the stronger the verification guarantees.” It checks the actor identity against the certificate and the predicate type, which defaults to https://slsa.dev/provenance/v1.

gh attestation verify example.bin --repo github/example
gh attestation verify example.bin --owner github --signer-repo actions/example

(Both are examples from the manual; github/example is a placeholder.) Useful flags documented in the manual:

• --signer-workflow or --signer-repo: needed when a reusable workflow produced the attestation.
• --deny-self-hosted-runners: fails verification for attestations generated on self-hosted runners.
• --bundle: verify offline from stored attestations.
• --format json: machine-readable output. The manual warns that only signature.certificate and verifiedTimestamps are tamper-resistant, and that statement.predicate can be falsified if an attacker controls the workflow, so policies should not rely on it alone.

That last warning is worth sitting with. If an attacker controls the build workflow, the provenance they get signed is truthful about which workflow ran, not about the workflow being benign. This is why pinning the expected signer workflow matters more than reading the contents.

What provenance does not prove

These are our conclusions from the framework’s definitions, not claims the specification makes in these words:

• That the source is trustworthy. Provenance links an artifact to a commit; it says nothing about whether the commit is malicious. Source controls are what the Source track is for.
• That dependencies are safe. Provenance records inputs; it does not vet them. See our guides to dependency audits without slowing releases and to what container image scanning still misses.
• That the software has no known vulnerabilities. For that you need an inventory (SBOM) and prioritization (CVSS, EPSS and KEV).
• That the build platform itself is uncompromised. The level is only as good as the platform’s isolation.

A practical adoption order (our suggestion)

1. Produce attestations for released artifacts only, on a hosted builder (this reaches L2 on GitHub per its documentation).
2. Write down the expected identity for each artifact: repository, and signer workflow if you use a reusable workflow.
3. Verify in the place where artifacts are consumed (deployment pipeline or admission step), failing closed on mismatch.
4. Move high-value artifacts to a reusable workflow to target L3, and test that your verification command pins that workflow.
5. Treat provenance as one control alongside SBOMs, dependency review and source protections.

Limits of this article

We did not run signing or verification ourselves. We did not read the SLSA Source track requirements, GitHub plan requirements, the Sigstore certificate lifetime, or any mapping of GitHub’s attestations to SLSA v1.2. The SLSA v1.1 pages we used for the provenance fields are retired.

Sources and verification

Checked on October 12, 2026.

A software bill of materials (SBOM) is, in the words of the guidance itself, “a nested inventory, a list of ingredients that make up software applications and systems.” On July 29, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), the Federal Bureau of Investigation (FBI) and agencies from other countries published the 2026 Minimum Elements for a Software Bill of Materials. It “updates and replaces” the Minimum Elements For a Software Bill of Materials that the U.S. National Telecommunications and Information Administration (NTIA) published on July 12, 2021. If you buy, build or operate software and you ask anyone for an SBOM, this is now the reference list of what to ask for.

This article is research-based: we read the full 2026 document, the 2021 NTIA document, and CISA’s announcement. We did not generate SBOMs with any tool or check how specific tools map to these fields.

What this document is, and what it is not

• Who published it: CISA with the NSA, the FBI and, according to the document’s header, 15 further organizations from other countries (among them Australia, Canada, France, Germany, India, Italy, Japan, the Netherlands, New Zealand, Poland, South Korea, Slovakia and the Czech Republic). Its acknowledgements note that the European Commission’s DG CONNECT contributed, but that the document does not interpret EU law and does not bind the Commission.
• Version history: version 1.0 was the NTIA document of July 12, 2021; version 2.0 was a public-comment draft of August 22, 2025; version 2.1, dated July 29, 2026, incorporates the comments received. CISA’s announcement says more than 90 comments were received.
• Not a mandate: the document states the minimum elements “do not create new requirements; they refine how organizations should generate and request SBOMs,” and its disclaimer says it is not advice for compliance, regulatory or legal purposes. Do not read it as a law. Individual contracts or regulations may point to it, but that is separate.
• Scope: it applies to SBOMs for all software, including open source, AI software and software as a service (SaaS). It says AI systems and SaaS may need additional elements, which are out of scope. For AI it points to separate G7 joint guidance published in May 2026.

What changed in the data fields

The 2021 document listed seven baseline data fields: Supplier Name, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data and Timestamp. The 2026 document’s Appendix A table lists 17 data fields, in two groups: SBOM Metadata (about the SBOM document) and Component Data (about each component).

CISA’s announcement names four new elements: Component Hash Algorithm, Component License, SBOM Tool Name and SBOM Generation Context. The document itself is more complete. Its Notable Updates section lists ten new elements: SBOM Author Signature, SBOM Data Format Name, SBOM Data Format Version, SBOM Generation Context, SBOM Tool Name, SBOM Tool Version, SBOM Version, Component Hash Value, Component Hash Algorithm and Component License. We count ten from that list; the announcement’s four are a subset, not a conflict.

A few details worth knowing:

• Why “Supplier” became “Component Producer”: the document says Supplier Name “has proven ambiguous in practice, particularly around distributors of software,” and that some ambiguity will remain even with the new name.
• Hashes: the Component Hash Value is computed over the executable component artifact. If the SBOM author does not have access to it, the document says to indicate the value is unknown. The algorithm should be identified using IANA Hash Function Textual Names and be approved by a relevant authority such as NIST.
• Generation context matters: the document’s example is that an SBOM generated from source code is “before build,” while one produced by binary analysis tools is “after build.” The same software can have different component data depending on when the SBOM is generated, so this field tells a reader how much to trust the data.
• Identifiers: a field may carry multiple identifiers; if there are several, the author should include all of them.

What changed in practices and processes

Coverage carries the biggest practical change. The document’s own illustration: from a vulnerability management view, the recipient of an SBOM “should be able to conclude that a newly reported vulnerability does not affect them if the SBOM does not list the component associated with the vulnerability.” That only works if the SBOM is comprehensive, including transitive dependencies (dependencies of your dependencies). It also allows linking to separate SBOMs for subcomponents, provided the recipient has access to all of them.

SPDX, CycloneDX and the format question

The document names two data formats as widely used: SPDX (System Package Data eXchange), cited with ISO/IEC 5962:2021, and CycloneDX, cited with ECMA-424, which it dates December 2025. It does not tell you to pick one. Producers choose “based on factors that may be specific to organizations, industries, or sectors,” while consumers “should accept any widely used, interoperable, and machine-processable SBOM format.”

For current version numbers, the CycloneDX specification overview showed version 1.7, released October 21, 2025, when we checked. The SPDX specifications page identified SPDX Document Version 3.0 as the current version; it shows no release dates for versions. We did not verify how each tool’s output maps onto the 17 fields. When evaluating a generator, check whether its output actually includes, for example, hash values, license identifiers and generation context, rather than assuming it does.

What this means in practice

These are our suggestions based on the guidance, not requirements in it:

1. Update the SBOM request language in vendor questionnaires. Instead of “provide an SBOM,” ask for one that satisfies the 2026 Minimum Elements, in a named format and version, with Coverage including transitive dependencies. See our guide to vetting third-party SaaS tools for the wider vendor review.
2. Check your generation tooling for the new metadata: tool name and version, generation context, timestamp, and a signature if you share SBOMs externally.
3. Generate at more than one point if you can. Because components differ by lifecycle phase, a source-based SBOM and a post-build SBOM are not interchangeable.
4. Pair SBOMs with vulnerability prioritization. An SBOM tells you whether you have a component; it does not tell you whether the flaw is exploitable in your product. The guidance points to VEX and CSAF for that; see how to read a VEX not-affected statement. Our comparison of CVSS, EPSS and KEV covers prioritization, and dependency audits without slowing releases and container image scanning cover where the component data comes from in CI.
5. Treat unknowns as data. Mark fields you cannot fill as unknown rather than omitting them, as the guidance asks, and treat “unknown” in a vendor SBOM as a follow-up question, not a pass.

Limits of this article

We did not verify the claims of third-party summaries that count the changes differently; we counted from the document. We did not check whether the U.S. federal procurement rules, the EU Cyber Resilience Act or any other regime now references the 2026 document. The document itself only notes that the EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to provide an SBOM as part of technical documentation, and states that it does not interpret EU law. Check your own contractual and regulatory obligations separately.

Sources and verification

Checked on October 11, 2026.

Content Security Policy gets most of the attention among HTTP response headers, but four smaller headers cover different problems: forcing HTTPS, stopping content-type guessing, limiting what a link leaks, and switching off browser features you never use. The values below come from OWASP’s HTTP Headers Cheat Sheet and MDN’s reference pages, and every claim is attributed to one of them. This is research-based; we did not run these headers against a live server or test browser behavior. For the script-control header, see our separate guide to a strict nonce-based Content Security Policy.

The short version

OWASP’s recommended values for the four headers:

OWASP gives these as recommendations; 63072000 is two years in seconds. Two of them need care before you copy them: the HSTS value includes preload, which has consequences described below, and the Permissions-Policy value disables only three features, so you should disable what your site does not need.

Headers are sent by the web server, CDN or application, and the configuration syntax differs between them. The examples here are the raw header lines as they appear in an HTTP response.

Strict-Transport-Security (HSTS)

HTTP Strict Transport Security (HSTS) tells a browser to access a host only over HTTPS. MDN defines max-age as “the time, in seconds, that the browser should remember that a host is only to be accessed using HTTPS.” Before loading an http URL for that host, the browser rewrites it to https.

Strict-Transport-Security: max-age=31536000; includeSubDomains

How it behaves, per MDN:

• HTTPS only. The header must be sent over HTTPS. Browsers ignore it over HTTP, which prevents a man-in-the-middle from setting or expiring it. Your HTTP-to-HTTPS redirect (MDN suggests a permanent redirect such as status 301) must not carry the header.
• First-visit gap. HSTS “does not take effect until the browser has made at least one secure connection to the host and received the Strict-Transport-Security header.” An insecure first request is vulnerable to network attacks. Preloading mitigates this.
• Refreshing. Each time the browser receives the header, it extends the expiry by max-age from the current time. MDN warns that a fixed max-age can keep HSTS from ever expiring while the header keeps being sent.
• Subdomains. includeSubDomains applies the policy to all subdomains of the host that sent it. MDN notes it does not apply to the parent domain or to sibling hosts.
• No click-through. If a TLS error such as an invalid certificate occurs on an HSTS host, the browser does not let the user proceed. OWASP makes the same point from the operator side: a misconfigured header or a certificate problem can block legitimate users, and long durations are a particular risk if the certificate expires or is revoked.
• Turning it off. max-age=0 disables it, but only once a browser makes a secure request and receives that response.

The preload decision

HSTS preloading ships your domain inside browsers so even the first visit is HTTPS. MDN says the list is maintained by Google at hstspreload.org, is used by all major browsers, and “is not part of the HSTS specification and should not be treated as official.”

hstspreload.org lists these submission requirements:

1. Serve a valid certificate.
2. Redirect HTTP to HTTPS on the same host if you listen on port 80.
3. Serve all subdomains over HTTPS, including www if a DNS record for it exists.
4. Send an HSTS header on the base domain with max-age of at least 31536000 seconds (one year), includeSubDomains and preload.

The site’s warning is blunt: “inclusion in the preload list cannot easily be undone.” Removal takes months to reach users through a Chrome update, other browsers are not guaranteed to honor it, and removal “tends to be slow and painful” for sites preloaded before they realized some subdomains lacked HTTPS.

Our editorial suggestion, not a quoted rule: because the header persists in browsers until it expires and max-age=0 works only after a secure request, start with a short max-age, confirm every subdomain (including internal ones) serves valid HTTPS, raise the value in steps, and add preload only as a deliberate, final decision. Before then, an internal hostname with an expired certificate becomes unreachable for users who cached the policy.

X-Content-Type-Options: nosniff

Browsers can try to work out what a file is from its content, called MIME sniffing, rather than trusting the Content-Type header. nosniff is the only valid value, and MDN describes two effects:

• For requests with a destination of script or style, the browser blocks the response if the MIME type does not match: a JavaScript MIME type for scripts, text/css for stylesheets.
• For other responses, including navigations to a new HTML document, the browser uses the supplied Content-Type as-is. MDN’s example: a text/plain response with nosniff will not be interpreted as HTML even if it contains HTML markup, which helps against attacks where user-uploaded content is executed as an HTML document.

X-Content-Type-Options: nosniff

The limitation is the part people miss. Blocking applies to script and style requests only, and everything depends on the declared type being right. OWASP’s pairing advice is to set Content-Type correctly throughout the site. If your server labels JavaScript files text/plain, nosniff will cause scripts to be blocked, which is a good way to find those mistakes in staging.

Referrer-Policy

When a user clicks a link or a page loads a resource, the browser may send a Referer header containing the address of the page that triggered the request. URLs can contain sensitive material such as password-reset tokens or internal paths, so Referrer-Policy controls how much is sent. MDN’s list of values:

MDN states that strict-origin-when-cross-origin is the default when no policy is specified, per a specification revision of November 2020, and that the previous default was no-referrer-when-downgrade. OWASP recommends the header with strict-origin-when-cross-origin and says to “Set the header explicitly rather than relying on browser defaults.”

Referrer-Policy: strict-origin-when-cross-origin

If your URLs carry secrets, the stricter no-referrer or same-origin send less; that comparison is our reading of MDN’s table, not a recommendation either source makes. The better fix is not to put secrets in URLs. MDN also documents a comma-separated fallback list with the preferred policy last, for example no-referrer, strict-origin-when-cross-origin.

Permissions-Policy

Permissions-Policy is a response header that, per MDN, “provides a mechanism to allow and deny the use of browser features in a document or within any <iframe> elements in the document.” Specifying () for a feature disables it for all browsing contexts, including iframes from any origin.

Permissions-Policy: geolocation=(), camera=(), microphone=()

MDN documents what happens when each is disabled: calls to getUserMedia() for camera or microphone reject with a NotAllowedError, and geolocation calls receive a PERMISSION_DENIED error. OWASP’s rationale is that the policy “prevents that an injection, for example an XSS, enables the camera.” Its advice is to disable every feature the site does not need, or allow it only for authorized domains.

Two qualifications. MDN labels the header “Limited availability” and “Experimental” and says it is not Baseline because it does not work in some of the most widely used browsers, so treat it as defense in depth rather than a guarantee. And you can scope a feature to specific origins, for example ("https://a.example.com"), rather than disabling it outright, if a legitimate embedded widget needs it.

Headers to stop sending

OWASP’s cheat sheet also names headers that should no longer be used:

• X-XSS-Protection: “Do not set this header or explicitly turn it off.” The example given is X-XSS-Protection: 0. OWASP says it can create XSS vulnerabilities in otherwise safe sites and points to a CSP that disables inline JavaScript instead.
• Expect-CT and Public-Key-Pins: do not use; remove from existing code where possible.
• Server, X-Powered-By, X-AspNet-Version, X-AspNetMvc-Version: remove, or set non-informative values.

OWASP also recommends X-Frame-Options: DENY against clickjacking but notes the CSP frame-ancestors directive obsoletes it for supporting browsers, and that it provides nothing for redirects or JSON API responses. For cross-origin access headers see CORS misconfiguration, and for another cookie- and header-based defense see CSRF protection with SameSite cookies, tokens and Fetch Metadata.

A rollout order that limits breakage

This ordering is our editorial judgment built on the behaviors above:

1. Audit what you send. Inspect responses for all hostnames, not just the main site, including error pages and redirects.
2. Add nosniff and fix any wrong Content-Type values it exposes.
3. Set Referrer-Policy explicitly. It is the lowest-risk change here.
4. Add Permissions-Policy disabling features you do not use.
5. Add HSTS with a short max-age, then raise it after checking every subdomain. Consider preload last.
6. Remove deprecated headers listed above.

Sources and verification

Checked on October 11, 2026. We read each page below; we did not test headers on a live server or in browsers.

A Content Security Policy (CSP) is an HTTP response header that tells the browser which sources of script and other content it may use on your page. The version worth deploying for cross-site scripting (XSS) defense is a strict policy based on a random per-response value called a nonce. MDN’s guidance reads: “To control script loading as a mitigation against XSS, recommended practice is to use nonce- or hash-based fetch directives.” OWASP’s cheat sheet likewise calls a strict CSP the “current leading practice.” This article covers the minimal strict policy, what each part does, and how to roll it out without a day of broken pages.

It is research-based. We tested only one thing ourselves: a small Node.js script confirming that the example below produces a different nonce on every response and that the header and page agree. We did not test browser behavior.

The minimal strict policy

MDN’s nonce-based example is:

Content-Security-Policy:
  script-src 'nonce-{RANDOM}';
  object-src 'none';
  base-uri 'none';

In plain terms:

• script-src 'nonce-{RANDOM}' allows a script only if its tag carries a nonce attribute matching the value in the header. Without nonce or hash expressions, MDN says, a script-src or default-src directive blocks inline JavaScript. That is the protection: an attacker who injects <script>alert(1)</script> does not know the nonce, so the browser refuses to run it.
• object-src 'none' disallows plugins and embedded objects. OWASP’s strict samples set it because, with plugin-types removed from the specification, object-src 'none' is the control when you do not need embedded objects.
• base-uri 'none' stops injected <base> elements from changing how relative URLs resolve. OWASP’s samples also set base-uri 'none'.

Add frame-ancestors 'none' if your pages should never be embedded in an iframe on another site. MDN says: “Unless you need your site to be embeddable, you should set frame-ancestors to 'none',” and describes it as a more flexible replacement for X-Frame-Options.

Generating the nonce

The rule from MDN: the nonce “must be different for every HTTP response, and must not be predictable.” Here is a minimal Node.js example (no framework) that does that:

const http = require("node:http");
const crypto = require("node:crypto");

http.createServer((req, res) => {
  const nonce = crypto.randomBytes(16).toString("base64"); // new value per response
  const policy = [
    `script-src 'nonce-${nonce}' 'strict-dynamic'`,
    "object-src 'none'",
    "base-uri 'none'",
    "frame-ancestors 'none'",
  ].join("; ");
  res.setHeader("Content-Security-Policy-Report-Only", policy); // switch to Content-Security-Policy to enforce
  res.setHeader("Content-Type", "text/html; charset=utf-8");
  res.end(`<!doctype html><script nonce="${nonce}">/* app code */</script>`);
}).listen(8080);

We ran an equivalent script twice against itself: the nonce differed between the two responses and the nonce in the body matched the header. That confirms the mechanics, not that your application is protected.

OWASP warns against one shortcut: do not use middleware that automatically adds the nonce to every script tag, because scripts an attacker injects would then receive the nonce too. The nonce belongs only on scripts your templates deliberately emit, which means your templating layer has to apply it.

Nonce, hash or 'strict-dynamic'

Per MDN, 'strict-dynamic' means that if a script has a nonce or hash, it may load further scripts that do not have one. It eases third-party scripts but moves some trust to them.

Why not just list allowed hostnames?

Allowlist policies such as script-src https://cdn.example.com were the original mechanism. OWASP says a strict policy is “much easier to deploy” and warns that a non-strict policy “that is too granular or permissive is likely to lead to bypasses.” We did not survey bypass techniques here and do not quantify how often they occur.

Roll it out in report-only mode first

The Content-Security-Policy-Report-Only header applies the policy in reporting mode. MDN: “The policy is not enforced, but any violations are sent to the reporting endpoint specified in the policy.” OWASP calls it non-blocking (“fail open”) and often a precursor to blocking mode. Practical points:

1. Report-only cannot be set in a <meta> element, per MDN and the W3C draft. The <meta http-equiv> form also “does not support all CSP features.” Use response headers, on all responses, not only the main document (MDN).
2. Both headers can run together. MDN says that if both are present, both policies are honored: the enforced one blocks and the report-only one reports. OWASP suggests running a strict report-only policy alongside a looser enforced one to collect many violation reports while you migrate.
3. Collect reports. MDN’s recommended method uses the Reporting API:

Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"
Content-Security-Policy: default-src 'self'; report-to csp-endpoint

Reports arrive as POST requests with content type application/reports+json and "type": "csp-violation". The older report-uri directive is described by MDN as deprecated, but it says to declare both until report-to is supported in all browsers. 4. Fix the causes, which are usually inline <script> blocks, inline event handlers such as onclick, and third-party snippets. Move inline code to external files or give emitted scripts a nonce. 5. Switch the header name from Content-Security-Policy-Report-Only to Content-Security-Policy once reports are quiet for your traffic, and keep reporting on.

Avoid the temptation to add 'unsafe-inline' to make reports go away. MDN: “Developers should avoid 'unsafe-inline', because it defeats much of the purpose of having a CSP.” It adds that when a directive has nonce or hash expressions, browsers ignore 'unsafe-inline' in it, so adding it beside a nonce does not weaken the policy in browsers that support nonces, but it also gains nothing there.

What CSP does not do

OWASP states that CSP “should not be relied upon as the only defensive mechanism against XSS.” MDN says the same thing differently: “Setting a CSP is not an alternative to sanitizing input. Websites should sanitize input and set a CSP.” Output encoding and safe templating remain the primary fix. CSP also does not address cross-site request forgery, misconfigured cross-origin access, or broken authorization; see our articles on CSRF protection and CORS misconfiguration.

A note on standards status: as of our check, CSP Level 3 is a W3C Working Draft (the page shows September 16, 2026 as its date), not a finished Recommendation. Browser support is what determines real behavior, so test the browsers your users have.

Sources and verification

Checked on October 10, 2026. We did not test a policy in any browser.

Cross-Origin Resource Sharing (CORS) headers answer one question: may script running on another website read this response? If your API answers “yes” to the wrong origin and also allows credentials, that website can read your users’ data using their own logged-in sessions. Most real CORS vulnerabilities come from a short list of origin-matching mistakes, and all of them are fixed the same way: compare the Origin header against an exact list.

What CORS actually controls

Browsers apply the same-origin policy: script loaded from one origin cannot read responses from another. An origin is the scheme, host and port together, so https://app.example.com and https://api.example.com are different origins. MDN describes CORS as “an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources.”

Three facts shape everything below:

• CORS relaxes a restriction; it does not add one. Without CORS headers, other origins cannot read your responses. Every CORS header you add widens access.
• CORS governs reading, not sending. For a simple request, which MDN defines as a GET, HEAD or POST using only safelisted headers and one of three content types (application/x-www-form-urlencoded, multipart/form-data or text/plain), the browser sends the request without asking first. CORS decides only whether the calling script gets the response. Other requests trigger a preflight OPTIONS request before the real one is sent.
• Browsers enforce it; servers do not. A command-line client ignores CORS entirely. PortSwigger puts it plainly: “CORS defines browser behaviors and is never a replacement for server-side protection of sensitive data.”

Credentials are what make it dangerous

By default, a cross-origin fetch() does not send cookies. A script must ask for them with credentials: "include", and the browser then makes the response available only if the server replies with Access-Control-Allow-Credentials: true.

The browser adds a second safeguard. MDN says that when responding to a credentialed request the server “must not specify the * wildcard” for Access-Control-Allow-Origin and must instead name an explicit origin. The same rule applies to the allowed headers, allowed methods and exposed headers.