v145 · Web APIs · Controlled Frame Context
Controlled Frame Context
What Controlled Frame is, how it compares to iframes and <webview>, the enterprise use cases it enables, and why SecurityInfo matters in this context.
Controlled Frame vs other embedding mechanisms
| Capability | <iframe> | <webview> (deprecated) | Controlled Frame |
|---|---|---|---|
| Embed arbitrary web content | Limited (same-origin or CORS) | Yes | Yes |
| Intercept network requests | No | Yes (webRequest) | Yes (webRequest) |
| SecurityInfo for TLS inspection | No | No | Yes (Chrome 145+) |
| Isolated storage | Shared (partitioned) | Yes | Yes |
| Available in | All web pages | Chrome Apps (deprecated) | IWA (Isolated Web Apps) |
enterprise use cases for SecurityInfo
// Controlled Frame is used by enterprise applications (IWAs) that need
// full control over embedded web content — kiosk browsers, enterprise
// SSO portals, content filtering proxies, etc.
// SecurityInfo enables:
// 1. Certificate pinning — block connections to untrusted CAs
// 2. TLS version enforcement — warn if site uses TLS 1.2 or weaker
// 3. Mixed content detection — identify insecure sub-resources
// 4. Security audit logging — record TLS posture of visited sites
// Example: enforce minimum TLS 1.3 in an enterprise kiosk
frame.request.onHeadersReceived.addListener(async details => {
const info = await frame.request.getSecurityInfo(details.requestId, {});
if (info.protocol !== 'TLS 1.3') {
// Log, warn user, or block the request
auditLog.write({ url: details.url, tls: info.protocol });
}
}, { urls: ['https://*/*'] });see also
scenario focus
Select a scenario to focus its rendered example and summary.