"Unsafe Assignment to innerHTML in Firefox Extension Submission – Need Guidance and Alternatives"

[koushik]

Hi Mozilla Team,

I’m currently developing a Firefox extension using Next.js as the frontend framework. During development, some dynamic components (toolbars, modals, etc.) are inserted into the DOM using innerHTML for convenience and performance.

However, upon submitting the extension to AMO, I encountered security warnings related to innerHTML usage, including for auto-generated files from the Next.js build process. The reviewer flagged these as unsafe even though:

• The HTML being injected is static and defined within the extension codebase (not influenced by external input).
• No user-generated or third-party content is involved in the DOM manipulation.
• Some flagged innerHTML assignments come from Next.js runtime-generated code, which is not directly written or modified by me.
  
  
  
  What I Need Help With:

1. How can I safely justify the use of innerHTML in my case, especially for static or framework-generated content?
2. How should I handle innerHTML usage in Next.js, given that it automatically generates some of these assignments? Are there known workarounds or build options?
3. Are there Mozilla-approved alternatives or libraries for injecting HTML safely that are suitable for use in browser extensions built with modern frameworks like Next.js?

[juraj.masiar]

When I’m submitting my speed dial for manual review, it always has 3 warnings, and all of them are innerHTML.

But my source code doesn’t use innerHTML anywhere. They are all coming from the Vue/Vuetify library I’m using.

I think if you remove your own usages of innerHTML, it should be OK.
And it’s often not that hard, for example:

document.body.appendChild(
  Object.assign(document.createElement('a'), {
    href: 'https://example.com',
    textContent: 'Example',
    onclick: () => alert('whoa!')
  })
);

Unless you need to create complex DOM, in that case, use some UI framework.

[dotproto (Simeon Vincent)]

@koushik

The reviewer flagged these as unsafe even though

@koushik, for clarity, are you referring to the “Unsafe assignment to innerHTML” warning you included as a screenshot in your post or did a reviewer reject a submission? I’m asking because if you’re referring to the screenshot, I’m pretty sure that message coming from the automated check that AMO runs upload a new version, not a human reviewer. That warning shouldn’t prevent you from submitting the version for review.

I’m not too familiar with Next.js. Is the version of the extension that you’re submitting building using produciton optimizations or is it a development build? Some frameworks and bundlers have different build processes depending on which environment you’re targeting. This is usually used to enable things like hot module reloading and skip things like tree shaking during development.

I dug around a bit and it appears that Next.js should use tree shaking when building. As such, I think the innerHTML references should be removed as long as nothing calls those code paths. Are you using (or do you have a dependency that uses) dangerouslySetInnerHTML? This is a React property that explicitly uses innerHTML under the hood.

[lionelw]

Would using the DOMParser API to convert a string into DOM be safe enough to avoid the warning?

[koushik]

@dotproto

@koushik, for clarity, are you referring to the “Unsafe assignment to innerHTML” warning you included as a screenshot in your post or did a reviewer reject a submission? I’m asking because if you’re referring to the screenshot, I’m pretty sure that message coming from the automated check that AMO runs upload a new version, not a human reviewer. That warning shouldn’t prevent you from submitting the version for review.

I’m not too familiar with Next.js. Is the version of the extension that you’re submitting building using produciton optimizations or is it a development build? Some frameworks and bundlers have different build processes depending on which environment you’re targeting. This is usually used to enable things like hot module reloading and skip things like tree shaking during development.

I dug around a bit and it appears that Next.js should use tree shaking when building. As such, I think the innerHTML references should be removed as long as nothing calls those code paths. Are you using (or do you have a dependency that uses) dangerouslySetInnerHTML? This is a React property that explicitly uses innerHTML under the hood.

Thanks for the detailed reply!

Yes, the warning actually came from the automated check, but in my case, the submission was rejected due to innerHTML usage. I am using dangerouslySetInnerHTML in a few places to render pre-defined HTML templates inside the extension UI — this is currently necessary for the functionality I’m building.

The build I’m submitting is a production build, generated using next build, so tree-shaking and other optimizations should be applied. However, since those components are still actively used, the dangerouslySetInnerHTML references remain in the final bundle.

To address the security concerns, I’m sanitizing all injected HTML using DOMPurify, and I’ll make sure to include a clear explanation and justification in the AMO submission notes.

Appreciate you looking into this — your input helped me better understand how AMO interprets these checks!

[koushik]

That’s a great question!

Unfortunately, using the DOMParser API on its own doesn’t bypass the AMO warning. Even though it avoids directly assigning to innerHTML, you’re still inserting HTML content into the DOM — which is what triggers the warning. From AMO’s perspective, any method that renders raw or dynamic HTML, including DOMParser + appendChild, is considered potentially unsafe unless it’s properly sanitized.