Secure, test, and publish
Protect extension pages
Keep executable code packaged locally, avoid dangerous HTML sinks, and use a restrictive content security policy.
8 minute lesson
Manifest V3 disallows remotely hosted executable code. This keeps reviewed package behavior from changing after publication.
Bundle dependencies, avoid eval and string-to-code APIs, keep inline scripts out, and render untrusted values as text. Do not weaken the extension page CSP to make an unsafe library work; choose code compatible with the security model.
Remote code includes more than a CDN <script>. Downloaded JavaScript, WebAssembly, strings evaluated as code, and libraries that fetch executable logic after review all break the packaged-code trust model. Remote JSON and APIs can provide data, but the package must decide how that data is interpreted.
Treat extension pages as privileged origins. A popup can call extension APIs, so an HTML injection there can become more serious than the same bug on an ordinary page. Prefer .textContent, .value, and explicit DOM construction. If sanitized rich content is truly required, use a reviewed packaged sanitizer and test its configuration with hostile input.
Keep web-accessible resources minimal. Declaring a file web-accessible lets matching pages request it; it does not make arbitrary extension APIs available, but it exposes assets and can reveal extension presence. Page Notes does not need to expose its popup or scripts to websites.
Search for remote executable URLs, inline handlers, innerHTML, insertAdjacentHTML, eval, new Function, dynamic script creation, and unnecessary web-accessible resources. Test hostile stored text in both popup and injected panel and inspect Network for unexpected code loads.
Lesson completed