Is it acceptable to set isExposed to true for Lightning Message Channels that don't expose sensitive information or for specific use cases?
Answer
**General Policy:**
It is not acceptable to set `isExposed` to true for Lightning Message Channels, even if they do not expose sensitive information. The requirement is to set `isExposed` to false to ensure security, as exposing the channel can pose risks regardless of the data's sensitivity.
**Specific Use Cases:**
- **Client Customization Hooks**: Not acceptable to expose Lightning Message Channels for client customization hooks
- **Visualforce Integration**: LMS channels used in Visualforce pages must not be exposed - the `isExposed` attribute should be set to `false`
**Justification Process:**
If exposure is absolutely necessary, developers can justify by:
1. Demonstrating that fields being communicated are non-sensitive
2. Providing detailed documentation explaining the integration use case and why exposure is necessary
3. Highlighting security measures taken
4. Including information as part of security submission for review
5. Providing detailed documentation explaining necessity and secure implementation
6. Validating that communication is limited to known and trusted components
7. Ensuring no sensitive information is transmitted
8. Highlighting additional validation or security measures to prevent misuse
9. Including false positive documentation with supporting evidence if applicable
**Alternative Approaches:**
Consider alternative secure methods like the `pubsub` module and provide rationale if these alternatives are not feasible for your specific use case.
Is it acceptable to set isExposed to true for Lightning Message Channels that don't expose sensitive information or for specific use cases?
Recommended Answer Update
**General Policy:**
It's not acceptable to set `isExposed` to true for Lightning Message Channels, even if they don't expose sensitive information. You'll need to set `isExposed` to false to ensure security, as exposing the channel can pose risks regardless of the data's sensitivity.
**Specific Use Cases:**
- **Client Customization Hooks**: Not acceptable to expose Lightning Message Channels for client customization hooks
- **Visualforce Integration**: LMS channels used in Visualforce pages must not be exposed - set the `isExposed` attribute to `false`
**Justification Process:**
If exposure is absolutely necessary, you can justify by:
1. Demonstrating that fields being communicated are non-sensitive
2. Providing detailed documentation explaining the integration use case and why exposure is necessary
3. Highlighting security measures taken
4. Including information as part of security submission for review
5. Validating that communication is limited to known and trusted components
6. Ensuring no sensitive information is transmitted
7. Highlighting additional validation or security measures to prevent misuse
8. Including false positive documentation with supporting evidence if applicable
**Alternative Approaches:**
Consider alternative secure methods like the `pubsub` module and provide rationale if these alternatives aren't feasible for your specific use case.
Reasoning
The answer was overly verbose and contained redundant information that made it harder to scan and follow. I streamlined the content by removing repetitive points in the justification process (points 2 and 5 were essentially duplicates about documentation) and made the language more conversational and direct following the brand guidelines. Changed 'The requirement is to set' to 'You'll need to set' and 'are not feasible' to 'aren't feasible' for a more natural tone. I selected the AvoidLmcIsExposedTrue rule because this FAQ directly addresses the exact security concern that rule is designed to detect - Lightning Message Channels with isExposed set to true. The FAQ provides comprehensive guidance on when this is acceptable (generally not) and what justification process developers should follow, which directly relates to helping developers understand and address violations of this security rule.