13.2 UI Security, Performance & Accessibility Patterns

13.2 UI Security, Performance & Accessibility Patterns

Quick Answer: Secure Lightning UI by never trusting the browser as a security boundary, blocking XSS (no careless DOM/HTML injection), and relying on CSP, Locker Service / Lightning Web Security, and server-side CRUD/FLS/sharing. Speed UIs with @wire/LDS caching, lazy loading, and fewer Apex round trips. Prefer base Lightning components for accessibility and use static resources for cacheable assets.

Section 13.1 covered where UI lives. This section covers how custom UI stays safe, fast, and usable—themes that appear in User Interface and cross-cut Security/Testing mindsets on Platform Developer I.

Security Mindset for Lightning UI

The browser is not your enforcement layer

Anything in LWC/Aura/Visualforce JavaScript can be inspected or manipulated by a determined user. Therefore:

• Authorization decisions belong in Apex (with sharing, explicit CRUD/FLS checks or Security.stripInaccessible, careful without sharing only when justified)
• UI hiding (CSS, lwc:if, disabled buttons) is UX, not security
• Never ship secrets (passwords, long-lived tokens, other users’ private data) to the client “because the component is hidden”

Exam scenarios that show a component filtering records only in JavaScript while Apex returns all rows are wrong—fix on the server.

Cross-site scripting (XSS)

XSS occurs when untrusted strings are interpreted as HTML/JS in the browser—for example, a Contact title of <script>…</script> or an image tag with an onerror handler if rendered unsafely.

High-risk patterns to avoid or tightly control:

Safer defaults:

• Render text through normal LWC template bindings ({name}) so content is treated as text
• Use base components (lightning-formatted-rich-text and related controls only with trusted or properly sanitized sources—and know rich text is a deliberate exception that must be handled carefully)
• Prefer structured UI (properties, slots, child components) over string-built HTML
• Validate and encode on the server when accepting HTML-ish input

Exam language: If a stem asks how to display untrusted user input safely, choose escaped text binding / avoid DOM injection, not “turn off Locker” or “use innerHTML for speed.”

Content Security Policy (CSP) in Lightning

Lightning Experience applies a Content Security Policy that restricts:

• Inline scripts (in many contexts)
• Loading JavaScript from arbitrary external origins
• Some dynamic code execution patterns

Implications for developers:

• Host libraries as static resources (or approved platform mechanisms) rather than hot-linking random CDNs when policy blocks them
• Prefer platform modules and LWC imports over injecting <script src="https://…"> tags
• CSP errors in the browser console often mean “this script/style source is not allowed,” not “Apex failed”

You do not need to memorize every CSP header directive for PDI, but you must associate Lightning + CSP with limits on inline/third-party script and the need for compliant asset loading.

Locker Service and Lightning Web Security (Conceptual)

Salesforce isolates components so that one component cannot casually reach into another’s private DOM or JavaScript context. Two related names appear in materials:

What you must retain conceptually (not engine internals):

1. Components are sandboxed relative to each other
2. You communicate via public properties, events, LMS, not by scraping another component’s internal nodes
3. Global browser APIs may be restricted or wrapped
4. Isolation supports multi-vendor / multi-team pages on one flexipage (AppExchange + custom + standard)

Do not answer exam questions with “use document.querySelector on the whole page to read another team’s component state.” That fights Locker/LWS design.

Avoid DOM injection and fragile DOM coupling

Beyond XSS, heavy manual DOM work is brittle under Locker/LWS and Shadow DOM:

• Use this.template.querySelector only inside your LWC for your own template elements
• Do not rely on global IDs from unrelated components
• Prefer declarative rendering (lwc:if, lists, base components) over imperative DOM construction
• When third-party libraries need a root node, isolate them carefully and understand security/CSP trade-offs

Performance Patterns

Lightning performance problems usually come from too much work on load and too many server round trips, not from “JavaScript is slow” in the abstract.

Prefer efficient data access

Anti-pattern: connectedCallback fires three imperative Apex methods that each re-query the same accounts on every component instance on the page.

Minimize Apex round trips

Bundle server work:

• One Apex method returning a DTO with all data the view needs beats five chatty methods
• Do not call Apex inside loops on the client for each row
• Push filtering/sorting to SOQL when it reduces payload and enforces security
• Debounce user input (typeahead) so you do not hit the server per keystroke without limit

Remember governors still apply on the server; chatty UI multiplies limit risk under concurrent use.

Lazy loading and progressive UI

• Do not load every related list, chart, and heavy datatable on first paint if the user may never open that tab
• Render expensive child components when a tab becomes active or a section expands
• Use spinners and partial UI so first interaction is fast
• Keep component trees shallow when possible; large nested trees increase render cost

Payload and render hygiene

• Query only needed fields
• Paginate large tables (lightning-datatable with server paging patterns)
• Avoid huge client-side arrays of entire sObjects for trivial displays
• Prefer SLDS/base components over giant custom CSS frameworks downloaded per page

Accessibility (Certification-Relevant Awareness)

Platform Developer I will not make you a full WCAG auditor, but you should know accessible UI is part of Lightning design and base components help.

Practical a11y checklist for custom UI

Exam heuristic: “Build an accessible form in Lightning” → base Lightning input components + labels, not raw unlabeled HTML inputs with click-only handlers.

ARIA roles such as aria-live, aria-label, and role="dialog" appear when custom non-base widgets are unavoidable. Misused ARIA is worse than none—prefer native elements first.

Static Resources and Caching

Static resources store CSS, JavaScript libraries, fonts, and images in the org:

• Referenced from LWC via @salesforce/resourceUrl/ResourceName (and VF via $Resource)
• Served with caching headers so browsers reuse assets across pages
• Versioned with the org upload; zip resources allow folder paths

Why exams mention them for performance:

• Cached assets reduce repeat download cost versus inlining large scripts in every component render
• Shared libraries load once and serve many components
• Combined with CSP-friendly hosting, static resources are the standard place for approved client libraries

Caveats:

• Large unoptimized libraries still hurt first load—prefer platform modules when available
• Cache behavior means users may keep an old file until resource updates and references refresh—plan cache-busting via updated static resource versions when releasing breaking JS changes
• Static resources are not a substitute for Apex security or secret storage

Putting Security, Performance, and A11y Together

A well-designed LWC record widget typically:

1. Uses @wire(getRecord) or cacheable Apex for reads (performance + platform cache)
2. Performs DML in non-cacheable Apex with sharing and FLS enforced (security)
3. Renders with lightning-record-view-form / inputs / datatable (a11y + less custom HTML)
4. Avoids innerHTML for user fields (XSS)
5. Lazy-loads secondary panels (performance)
6. Loads optional charting CSS/JS from a static resource if not available as platform modules (CSP + caching)

Anti-pattern summary the exam wants you to reject

Bottom line: For Platform Developer I, UI quality means secure by server enforcement and no XSS/DOM injection, isolated by Locker/LWS, fast via wire/LDS, lazy load, and fewer round trips, accessible via base components and basic ARIA/label discipline, and efficient assets via static resource caching—all while composing on the Lightning pages you designed in 13.1.