ASVS 5.0 requirement V3.7.1 says the application may only use client-side technologies that are still supported and considered secure. NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NaCl and client-side Java applets do not qualify. It is a Level 2 requirement.
Why it matters
These runtimes no longer receive security fixes, and modern browsers have removed them. What remains are old intranet apps, embedded players and admin tools that force users onto outdated browsers or special builds, which widens the attack surface of every machine that runs them.
How to implement it
Find and replace. Typical swaps: Flash video and games to HTML5 video and canvas, Silverlight and ActiveX data grids to a JavaScript front end, Java applets for file upload to the File API and fetch, and signing plugins to WebAuthn or server side signing.
Block legacy content while you migrate: a Content Security Policy with object-src 'none' stops object and embed plugin content, see V3.4.3.
How to test it
Search templates and static files for the old markers:
grep -RIlE "<object|<embed|\.swf|\.xap|\.jar|applet|ActiveX|classid=" ./public ./templates
Crawl the live site and look at responses with plugin MIME types such as application/x-shockwave-flash. Ask support whether any customer is told to use a legacy browser mode.
Common mistakes
Forgetting internal tools. They hold the most plugins.
Keeping a plugin path for a few customers. It still counts.
Removing the tag but not the file. Delete old assets.
Quick check
Does WebAssembly count?
No. It is a standard supported by all major browsers, and it runs in the browser sandbox.
Sources
- OWASP ASVS 5.0, requirement V3.7.1
