Mixed content occurs when an HTTPS page tries to load an HTTP resource. Browsers block this before CORS is evaluated because it weakens the security of the encrypted page. It is often mistaken for a CORS failure even though the enforcement layer is different.
Expanded Definition
Mixed content is a browser security condition, not an IAM control, and it appears when a secure HTTPS document attempts to fetch an insecure HTTP asset such as an image, script, iframe, or API endpoint. The browser blocks the request because the insecure dependency can undermine the confidentiality and integrity guarantees of the encrypted page. In practice, the term is often discussed alongside transport security, Content Security Policy, and browser hardening, while the underlying policy model remains distinct from CORS and authentication. Definitions vary across vendors when application teams describe any failed cross-origin fetch as "mixed content," but the strict browser meaning is narrower and more precise, as reflected in guidance such as the NIST Cybersecurity Framework 2.0 emphasis on secure communications and protected data flows. In NHI environments, the issue matters because agents, service accounts, and internal tools often call external APIs or load embedded resources from legacy endpoints. The most common misapplication is treating mixed content as a CORS defect, which occurs when teams fix the wrong layer after a blocked HTTP resource appears in browser console logs.
Examples and Use Cases
Implementing mixed-content prevention rigorously often introduces migration friction, requiring organisations to balance rapid delivery against the cost of remediating legacy HTTP dependencies.
- A dashboard served over HTTPS loads a chart library from an HTTP CDN, and the browser blocks the script before any cross-origin policy is evaluated.
- An admin portal embeds an HTTP image from an old asset host, creating passive mixed content that may render inconsistently while still weakening the page’s trust boundary.
- An agentic workflow calls a legacy HTTP webhook from a secure web UI, causing the request to fail even though the service account credentials are valid.
- A product team upgrades a SPA to HTTPS but leaves one internal API route on HTTP, so the browser blocks the fetch and the failure is incorrectly triaged as authentication error.
- During hardening, teams use the Ultimate Guide to NHIs to review how machine-to-machine calls, secrets, and endpoint trust assumptions intersect with browser-facing workflows.
Browser enforcement is described in platform security guidance, and the practical remediation pattern is usually to move every dependent resource to HTTPS, proxy it through a trusted service, or remove the dependency entirely. For teams standardising controls, the NIST Cybersecurity Framework 2.0 is a useful reference point for identifying insecure communications as part of broader protection activities.
Why It Matters in NHI Security
Mixed content becomes operationally important when identity-related workflows depend on browser-delivered admin consoles, agent control planes, or embedded status pages. Even if the credentials are sound, an insecure asset can prevent the page from loading correctly, hide telemetry, or break the operator path needed to approve, revoke, or investigate an NHI. That is why governance teams should treat browser transport hygiene as part of identity assurance, not just front-end cleanup. The operational impact is amplified when secrets, tokens, or device links are surfaced in interfaces that pull data from multiple services, because one insecure dependency can interrupt the entire workflow. NHI Mgmt Group research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes adjacent transport mistakes even harder to spot. The same Ultimate Guide to NHIs also underscores why visibility and rotation discipline matter when a browser surface is part of the operational chain. Organisaties typically encounter this consequence only after an admin page, incident console, or automation UI stops rendering correctly, at which point mixed content becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Mixed-content issues often expose insecure secret and endpoint handling in NHI workflows. |
| NIST CSF 2.0 | PR.DS | Broken secure transport maps to protecting data in transit and secure communications. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero Trust requires trustworthy transport for requests and resources across boundaries. |
Treat insecure web dependencies as trust violations and enforce encrypted paths for every control-plane asset.
Related resources from NHI Mgmt Group
- Why do attackers often check model availability before trying to generate content?
- What is the difference between content inspection and identity-aware data protection?
- What is the difference between AI content risk and AI identity risk?
- How should security teams govern AI services that can generate offensive content?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
