🛡️ Lightning Web Security (LWS) vs. Locker Service: The Ultimate Guide

💬 In plain words: Locker Service and its modern successor, Lightning Web Security (LWS), act as strict security sandboxes for your Salesforce components. They wrap browser APIs to guarantee that one component cannot spy on or manipulate another. This prevents malicious or poorly written AppExchange packages from stealing data. LWS is the current standard—providing the same robust protection as Locker, but with far fewer mysterious breakages when using third-party libraries.

Key Points

• Locker is legacy; LWS is the future: Salesforce enables LWS by default in new orgs to replace the older, highly restrictive Locker Service.
• Namespace isolation remains: Both frameworks ensure that components from different namespaces cannot interfere with each other.
• Third-party library friendly: LWS uses standard JavaScript sandboxing instead of heavy custom proxies, meaning charting, UI, and utility libraries are much more likely to work out of the box.
• Better performance: Stripping away Locker's heavy DOM wrappers allows LWS to run code faster and closer to native browser speeds.

🧠 Sandbox around the sandbox: LWS isolates components by namespace without breaking native JavaScript APIs. Shadow DOM forms wall one; LWS forms wall two.

Understanding the Shift: Why LWS?

To safely run multiple custom components and AppExchange packages on a single page, Salesforce needs to sandbox them. Without a sandbox, any script on the page could read sensitive data directly from the DOM.

• The Legacy Approach (Locker Service): Locker wrapped the DOM and global objects (like window) in heavy, secure proxies. While safe, this caused major headaches. Standard JavaScript identity checks failed, deep DOM manipulations crashed, and third-party libraries constantly broke. Performance also took a hit due to the proxy overhead.
• The Modern Approach (Lightning Web Security): LWS replaces Locker with true JavaScript sandboxing. Instead of wrapping everything in proxies, it gives each namespace its own adjusted global environment. It behaves much closer to native JavaScript.

📌 Real-Life Example: Imagine an older JavaScript charting library. Under Locker, it immediately crashes because it attempts to interact with global window variables that Locker's proxy outright blocks. Under LWS, if you load that exact same library from a Static Resource, it initializes perfectly. LWS allows the native API calls but still prevents the chart from reaching into a different namespace's DOM. You get the same security guarantee with fewer casualties.

🧭 360 Card — LWS vs. Locker

• Rule: LWS is the modern sandbox; Locker is the legacy sandbox. Both stop cross-namespace spying.
• Gain: You can safely run multiple, untrusted AppExchange packages alongside your proprietary code on a single page.
• Price: Libraries that heavily modify window and document globals struggled under Locker. Some edge cases still require tweaks under LWS.
• Limits: Locker broke instanceof checks and deep DOM queries. LWS solves this by sandboxing per namespace, though Shadow DOM still prevents cross-component DOM reading.
• Mirror (No sandbox): Everything works perfectly on the first try, but any component can steal any other component's data. A massive security risk.
• Actionable Advice: Always check if your org runs LWS or Locker before debugging mysterious frontend errors.

⚠ INTERVIEW TRAP: Saying "Lightning Web Security is friendlier than Locker" does not mean it is unrestricted! LWS still strictly enforces cross-namespace isolation and Content Security Policy (CSP). Never assume a library will work; always test it.

Core Q&A

Q: What specific code broke under Locker that behaves better under LWS, and what does LWS still restrict?

🎯 Say this first: Libraries touching window and document globals broke under Locker's heavy proxies. LWS sandboxes per namespace with fewer breakages, but it still strictly enforces CSP and cross-namespace isolation.

Locker's proxies broke standard web libraries in three main ways:

• Identity checks failed because instanceof ran against a wrapped proxy object instead of the real native object.
• Deep DOM manipulation and anything touching restricted globals threw immediate errors. Charting tools and rich-text editors were notorious for this.

LWS runs your code against APIs that are slightly distorted for security, but remain native-shaped. Because the proxy overhead is gone, most of these libraries now just work, and they execute much faster.

However, LWS still restricts:

• Cross-namespace access: You still cannot reach into another namespace's components or global variables.
• Dangerous APIs: Highly exploitable document and window capabilities remain distorted for safety.
• Network Requests: Content Security Policy (CSP) still completely governs what network requests and remote scripts are allowed.

Q: How do you check if Lightning Web Security is actually enabled in your org?

Go to Setup > Session Settings. Scroll down to the "Lightning Web Security" section. Look for the checkbox labeled "Use Lightning Web Security for Lightning web components and Aura components." If checked, LWS is handling the sandboxing. If unchecked, your org is still relying on the legacy Locker Service.

Q: A third-party library works perfectly in a plain HTML page but throws errors in your LWC. What is your debugging path?

Walk through these four troubleshooting steps:

• Verify the sandbox: Confirm whether the org is running LWS or Locker in Session Settings, as the root cause will differ dramatically.
• Check the console: Look at the browser developer tools for CSP violations (e.g., blocked network requests) or blocked dangerous code executions like eval().
• Load locally: Never load complex libraries via remote scripts. Always upload the library as a Static Resource and load it using platformResourceLoader.
• Test in isolation: Spin up a Scratch Org with LWS enabled to isolate the issue. If the library fundamentally relies on document.write or unsafe eval(), it cannot be used in LWC. You will need to find an alternative library or load it inside an iframe using Visualforce.

Q: Security asks: "Can one AppExchange package's component read our proprietary component's data on the same Lightning page?" How do you answer?

Namespace isolation is the core design goal of both LWS and Locker. Each namespace receives its own isolated view of the global environment. Additionally, standard Shadow DOM blocks cross-component DOM queries.

However, precision is key. While the DOM is locked down, components still share the broader page context. Therefore:

• Anything broadcast over a Lightning Message Service (LMS) channel can be read by any component subscribed to it, regardless of namespace.
• Data placed into unscoped, shared browser state (like sessionStorage) may be vulnerable if not handled carefully.
• Most importantly, frontend sandboxing does not restrict the backend. An AppExchange package's Apex code runs with whatever object and field permissions it was granted during installation. Always review what the package's server-side code is permitted to do.