Custom Apex that serves a Lightning component must not assume that the client-side component has already enforced the user ' s data access. Apex can execute in system context, so the development team must explicitly preserve record visibility and enforce the user ' s CRUD and Field-Level Security where appropriate. The record-level requirement can be handled with the correct sharing declaration or user-mode operations, while object and field authorization can be enforced through user mode, Security.stripInaccessible(), or valid Schema Describe checks. Creating runAs tests is valuable for verification but does not secure production execution. Likewise, method names such as isShareable are not valid substitutes for the platform ' s real security APIs. The architectural principle is to treat the LWC-to-Apex boundary as a server-side trust boundary: every Apex entry point should return only records and fields that the running user is entitled to access. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - system-mode Apex, record-sharing enforcement, CRUD/FLS, user-mode operations, and Lightning/Apex security boundaries.