How to restrict SWF content from HTML

When you host SWF content inside HTML, you have a few tools at your disposal to control how much privilege that SWF has. If you are hosting SWFs that you created or trust completely, these may be unnecessary, however you may find them useful otherwise.

When specifying container tags (i.e. OBJECT or EMBED), you can optionally provide one of the following two parameters: “allowScriptAccess” and “allowNetworking”. These tags can only be specified within HTML (not from a SWF itself), and apply to that root SWF and any other SWFs the root SWF may load.

“allowScriptAccess” controls the ability of the SWF to call into the browser’s JavaScript DOM. This means the SWF could inject script into the website that is hosting it, which can be either dangerous, or at least not desirable (as the SWF could open new windows, inject JavaScript into the surrounding HTML, redirect the current window, read cookies, etc.)”allowNetworking” affects the ability of a SWF to perform network I/O, either via the browser (opening new windows, etc.) or directly using Flash networking APIs. This implicitly may also restrict scripting access to the browser, as you cannot prevent network I/O without prohibiting access to the browser’s JavaScript DOM.In order of least to most restrictive, you can specify:”allowScriptAccess=always”: This permits the SWF to call arbitrary browser JavaScript at all times, even if the SWF came from another domain. This is generally not safe to do unless you completely trust the SWF you are loading (and any children SWFs it may subsequently load).”allowNetworking=all”: All normal network I/O is allowed (as permitted by the Flash Player security model).”allowScriptAccess=sameDomain”: This permits the SWF to call into the browser’s JavaScript DOM only if the SWF came from the same domain as the HTML hosting it. This is equivalent to the typical browser “same origin policy” model.”allowScriptAccess=never”: The SWF is never permitted to call into the browser’s JavaScript, even if it came from the same domain as its HTML container. You can use this tag if you host SWFs in the same domain as the HTML, but don’t trust the SWFs to interact with the surrounding HTML, cookies, etc. In particular this setting will also prevent the SWF from modifying or redirecting existing frames windows. However, if you really don’t trust the SWF you may need some stronger medicine.”allowNetworking=internal”: Everything with “allowScriptAccess=never” applies, and also prevents the SWF from opening new browser windows, modifying existing ones, or otherwise affecting any browser state. The SWF can still use internal networking ActionScript APIs like loadMovie(), XML.load(), LoadVars, etc.Finally, “allowNetworking=none” prohibits any browser or network interaction. This means that the SWF cannot do much more than interact with the assets it contains internally, and cannot do anything to influence the browser, or load or send any data over the network.In addition, Flash Player integrates with the browser’s pop-up blocking technologies to ensure that windows that could not be opened directly via HTML/JavaScript will be blocked in Flash as well.The safest strategy is to always explicitly set the parameter value you want, so you don’t have to worry about what the behavior will be on a given situation.For additional details on the allowScriptAccess tag, see additional details on the allowNetworking tag, see

5 Responses to How to restrict SWF content from HTML

  1. Bob says:

    Would allowNetworking=internal prevent the swf from trying to access sounds (SoundMixer.computeSpectrum) from other domains? Or is there no way around restricting sandbox security for streaming sounds?

  2. Lucas Adamski says:

    Hi Bob,Setting allowNetworking=internal would not change the ability of a SWF to access computeSpectrum for cross-domain sound files. Cross-domain data access (including SoundMixer.computerSpectrum) is really managed by policy files.See for more information.

  3. Lucas,Thanks for starting this blog. Flash Platform security is one of the more “arcane-knowledge-required” parts of front-end development these days. I can’t count the amount of times I have wasted dealing with the security implications of scaling a new Flash or Flex app from the loose local testing situation to an enterprise production or QA environment.I hope you keep up with this blog, it’s definitely a welcome addition to my RSS reader.- KevinComcast Interactive

  4. Sagnik Banerjee says:

    Hi Bob,thanks for this blog. I really liked this a lot. These things should be kept in mind of every flash developer while uploading the flash content onto the web.

  5. Mark Harbur says:

    Is it possible to set scriptaccess per page with a meta tag instead of an embed? This would be good as a global override to self installed swf’s..[Lucas:] Unfortunately, there is currently no way to use a meta tag (or any other mechanism to control allowScriptAccess on page-wide basis). You could in theory write some a custom JavaScript method to insert the necessary embed/object tags and ensure the parameter is set correctly every time.