Insecure Design

As a best practice, flows should be restricted to specific users. Omitting restrictions gives all users the possibility to invoke a flow, which is typically undesirable.

Profiles define how users access objects and data and what they can do within the application. Granting "ViewAllData" or "ViewAllRecords" permissions at the profile level overrides any other record-level access mechanism and may give users excessive data access privileges.

The act of creation of an object should not alter data on the server-side or have any other significant side-effect. For this reason, using DML statements inside constructors is considered unsafe.

As a best practice, the registration of new platform users should be somewhat controlled or limited (i.e. using Captcha) to avoid being hijacked by malicious actors and prevent consuming an uncontrolled amount of licenses.

Lightning Web Components use Shadow DOM to protect the component from being manipulated by arbitrary HTML, CSS, and JavaScript. Bypassing the Shadow DOM gives developers greater control but is strongly discouraged as it significantly increases the risk of Cross-Site Scripting (XSS) and code injection vulnerabilities.

Clickjacking, also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they intended to click on the top-level page. Thus, the attacker is "hijacking" clicks meant for a page and routing them to another page.

When creating APIs that send emails programmatically, it's essential to include logic to ensure that messages get sent only if certain conditions apply (for example, CAPTCHAs) to reduce the risk of spamming by bots, sometimes also known as "email flooding".

As a best practice, the creation of a user's password should be managed by the platform. Setting a password programmatically increases security risk and, in most circumstances, isn't required.

Handling sensitive fields in the UI requires extra caution and should be planned carefully.

When using "not equal" conditions, a sharing rule operates on an opt-out basis, meaning that the sharing occurs unless certain non-sharing conditions are met. As a best practice, especially when sharing CRM data with external users, one should define the sharing rules on an 'opt-in' basis. This approach keeps data private by default and opens up visibility exclusively when specific conditions apply.