policy2

Fix “Permissions Policy Violation: Microphone and Camera Not Allowed in This Document” (Complete Guide)

If you are building a video chat, WebRTC application, or live streaming platform, you may encounter the following error in your browser console:

Permissions policy violation: microphone is not allowed in this document
Permissions policy violation: camera is not allowed in this document

This error commonly appears when accessing microphone or camera inside an iframe, especially in WebRTC applications such as video chats, conferencing platforms, or live streaming tools.

In this article, we will explain:

  • What this error means
  • Why browsers block camera and microphone in iframes
  • How to fix the problem correctly
  • Best practices for WebRTC applications

What Does the Permissions Policy Error Mean?

Modern browsers such as Chrome, Edge, and Firefox enforce strict security rules for sensitive devices like:

  • Microphone
  • Camera
  • Screen capture
  • Geolocation

These features are controlled by something called the Permissions Policy (previously known as Feature Policy).

When a website tries to access the camera or microphone inside an iframe, the browser checks whether the parent page allows it.

If permission is not granted, the browser blocks the request and generates the error:

Permissions policy violation: microphone is not allowed in this document

This means the iframe does not have permission to access the device.


Why This Error Happens

There are several common reasons why this issue occurs.

1. Missing allow Attribute in the iframe

The most common cause is that the iframe does not explicitly allow access to the camera and microphone.

Example of a basic iframe:

<iframe src="https://example.com/video-chat"></iframe>

This iframe will not allow camera or microphone access.

To fix this, you must explicitly grant permissions.

Correct version:

<iframe
src="https://example.com/video-chat"
allow="camera; microphone">
</iframe>

This tells the browser that the iframe is allowed to request those permissions.


2. Permissions Policy HTTP Header Blocking Devices

Even if your iframe is configured correctly, your server may still block device access using a Permissions-Policy HTTP header.

Example of a restrictive header:

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

This configuration explicitly disables camera and microphone for the entire page, including embedded iframes.

To fix this, update your server configuration.

Example for Apache:

Header set Permissions-Policy "camera=*, microphone=*"

Or allow a specific domain:

Header set Permissions-Policy "camera=(self https://example.com), microphone=(self https://example.com)"

This allows the iframe to access devices.


3. Cross-Origin iframe Restrictions

Browsers apply additional security restrictions when an iframe loads content from another domain.

For example:

Parent site:

https://mysite.com

Iframe content:

https://html5-chat.com

Because the iframe is cross-origin, the browser requires explicit permission through the allow attribute.

Correct configuration:

<iframe src="https://html5-chat" allow="camera; microphone; autoplay">
</iframe>

Without this attribute, camera and microphone access will be blocked.


4. Security Plugins or Reverse Proxies

Sometimes the issue is caused by security middleware rather than your code.

Examples include:

  • Cloudflare security headers
  • WordPress security plugins
  • Nginx reverse proxy headers
  • Content Security Policy rules

These systems may automatically add restrictive headers like:

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

To diagnose this issue, inspect your response headers using the browser developer tools.


How to Diagnose the Problem

Follow these steps to identify the cause.

Step 1 — Open Developer Tools

Press:

F12

Then open the Network tab.

Select your page request and inspect the Response Headers.

Look for:

Permissions-Policy

If you see:

camera=()
microphone=()

then your server is blocking device access.


Step 2 — Test the Page Without an iframe

Open the video chat page directly:

https://html5-chat/chat

If camera and microphone work normally, the problem is specifically related to the iframe configuration.


Best iframe Configuration for WebRTC Applications

For applications using WebRTC, video streaming, or live chat systems, your iframe should include all necessary permissions.

Example:

<iframe src="https://example.com/video-chat" allow="camera; microphone; autoplay; display-capture" allowfullscreen style="width:100%; height:100%; border:0;">
</iframe>

This configuration allows:

  • Camera access
  • Microphone access
  • Autoplay media
  • Screen sharing

Best Practices for Video Chat Platforms

If you are building a platform using WebRTC, mediasoup, or WebSockets, consider the following best practices.

Avoid unnecessary iframes

Camera access is generally more reliable when the application runs directly on the page rather than inside an iframe.

Always use HTTPS

Browsers block microphone and camera access on insecure connections.

Your application must run on:

https://

Request permissions only when needed

Instead of requesting camera and microphone immediately, request them when the user clicks a button such as:

Start Camera
Join Video Chat
Start Streaming

This improves user experience and reduces permission denial.


Conclusion

The error “Permissions policy violation: microphone or camera is not allowed in this document” is a common issue in modern web applications that use video, audio, or WebRTC technologies.

The problem usually comes from one of three sources:

  • Missing allow attributes in the iframe
  • Restrictive Permissions-Policy HTTP headers
  • Cross-origin iframe security restrictions

By properly configuring your iframe permissions and server headers, you can ensure that your application can access the camera and microphone without issues.

This is especially important for platforms that rely on live streaming, video conferencing, or real-time chat systems.

Vp8 and H264 codec which one should I use ?

Html5 chat supports now H264 and vp8 codecs

For now, we only used H264 to support Safari.

Unfortunately H264 is very old codec  and has some big drawbacks:

  • bigger bandwidth consumption
  • lower quality
  • lower reliability

Vp8 has all qualities except.. it is not supported on Safari.

You can choose the codec selection form the config/webcam chatadmin panel

What about Microsoft Edge ?

Forget Edge compatibility for now, since Edge will be based on Chromium from early 2019 and thus will have vp8

Notice that we will add new vp9 soon that will increase quality of video. Of course Vp9 is not supported by safari.

Notice that soon, all majors browsers should adopt AV1, that will end the war between all these codecs.

turn

HTML5 chat goes now TURN for better compatibility

HTML5 now embeds a TURN server

We just added TURN server to out webrtc version.

The goal is to make the traversal of NAT easier for systems behind firewalls and routers (allow port 3478)

The other interesting feature is to make the chat more compatible on IOS and Safari: Safari rules for webrtc are:

“You cannot play webrtc if you don’t publish yourself”

which is very blocking for conferences sessions or just to watch videos without having to allow access to its own webcam.

Thanks to Turn server, we can now bypass that Safari and IOS rule.

 

webrtc

HTML5 goes webrtc now !

A very import news : HTML5 chat enables WEBRTC support

webrtc
webrtc

that’s a great news: HTML5 supports both: Flash and Webrtc : you can choose that feature from your chatadmin panel.

Each technology has pros and cons:

Flash

Flash is used for streaming – that means ONLY flash based devices could stream. However all devices can watch the video.
Those with flash have real time video. Those without use HLS and have about 5 seconds of delay.

Webrtc

Webrtc is used for both streaming and playing. This technology is for now ONLY supported by chrome and Firefox browser.
It also works on Android.
Quality is superior to flash. It also includes a better echo cancellation algorithm.

However the latest Safari11 and IOS11 webrtc support is insufficient. Safari uses the old H264 codec. Besides, teh IOS webrtc support uses and old API