Three generations of Salesforce's client-side JavaScript security models.
Aura Locker (legacy) — for Aura Components. Stricter sandbox; limited DOM access; locked global objects (window, document); inter-component communication restricted.
Lightning Locker (current default for Aura/older LWC orgs) — evolved from Aura Locker. Same general principle: each component runs in a security wrapper preventing access to other components' DOM, locked globals, restricted JavaScript features.
Lightning Web Security (LWS) (newer, opt-in) — replaces Lightning Locker for LWC components. Less restrictive, more standards-compliant, better performance. Uses native browser features (Trusted Types, Constructable Stylesheets) instead of JavaScript proxies.
Key differences:
| | Lightning Locker | LWS | |---|---|---| | Performance | Heavier (proxy-based) | Lighter (native) | | DOM access | Wrapped, restricted | More direct (still controlled) | | 3rd-party libraries | Many incompatibilities | Fewer incompatibilities | | Setup | Default | Opt-in: Setup -> Lightning Web Security | | `window` / `document` | Locked clones | Direct access (with policy) | | Cross-component DOM | Blocked | Blocked but cleaner errors |
Migration considerations:
- LWS is more permissive but stricter on certain things — code that worked under Locker may fail under LWS, and vice versa.
- Test thoroughly when switching.
- 3rd-party libraries: many that didn't work under Lightning Locker work fine under LWS.
Common issues:
- `Object.assign` not blocked under LWS but custom prototype mods are detected.
- `eval` is blocked under both.
- `postMessage` between iframes — different rules.
For new LWC orgs, enable LWS from day one — better future. For legacy orgs with Aura + LWC mixed, carefully evaluate; some Aura components may break.