No. The async and defer attributes control when the browser fetches and runs a script, which helps page speed. They do not limit what the script can read or send once it runs. A script loaded with async has the same access as one loaded without it.
What each attribute does
The MDN documentation for the script element describes both. With async on a classic script, the script is fetched in parallel with parsing and runs as soon as it is available. With defer, the script is fetched while the page parses and runs after the document has been parsed, before the DOMContentLoaded event fires.
MDN also notes that a script with neither attribute blocks parsing, though not rendering. That is the performance reason store teams add them to marketing tags: the page should not wait for a vendor server.
| Attribute | Fetches | Runs | Typical use |
|---|---|---|---|
| none | Blocks parsing | Immediately | Code the page needs right away |
| async | In parallel | As soon as ready, order not guaranteed | Independent tags such as analytics |
| defer | In parallel | After parsing finishes, in order | Scripts that need the full page |
Why speed settings are not security settings
Both attributes only change timing. Once the script executes, it runs with the privileges of your page. It can read the visible fields, add its own elements and make network requests, the same as before.
The OWASP cheat sheet makes the point in terms of risk: loading third-party JavaScript means accepting loss of control over changes, execution of arbitrary code on client systems, and disclosure of sensitive information. None of those risks changes with a loading attribute.
A common mistake is treating a fast, non-blocking tag as a low-risk tag. A tag on the checkout page that loads with async is exactly as able to read a card field as one that loads synchronously.
What actually limits a script
Different tools address different parts of the problem:
- Subresource Integrity makes the browser compare the downloaded file with a hash you supplied, and refuse it if it differs. MDN describes this as a defense against a compromised third-party host.
- Content Security Policy restricts which sources scripts may load from, and can block inline scripts that lack a nonce or hash.
- Sandboxed iframes keep a widget away from your page's DOM and cookies.
- Removing the script from sensitive pages is the strongest option where the business case is weak.
Use async or defer for speed, and use the controls above for safety. Keep the two decisions separate in your review notes so nobody signs off on a tag because it is fast.
A short review rule
When someone asks to add a vendor tag to a store page, ask two questions in order. First, which page types will it run on, and does it need to run on checkout at all? Second, how will it load: async, defer or inline, and is there a hash or policy in place? The second answer is about performance. The first one is about risk.
Try it yourself
Click through it at your own pace, or open it full screen. Notice that an inventory lists what is present, regardless of how fast or slowly it loads.
Where Safeguard fits
For packages bundled into your storefront code, Safeguard's SBOM and dependency scanning shows what you ship, with reachability analysis to help rank findings. A free scan is at gold.safeguard.sh/scan.
Quick check
Should a marketing tag use async or defer?
Usually yes for speed, since it stops the tag blocking page parsing. Treat that as a performance choice only.
Does defer keep a script away from the checkout form?
No. It delays execution until parsing finishes, and then the script can still read the page.
Sources
Last reviewed: 19 October 2026.
