FAQ-000274 - CSS and UI Security / Clickjacking Vulnerabilities and CSS Positioning

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
When is absolute or fixed positioning acceptable and what are the security review criteria?
Answer
Absolute or fixed positioning is acceptable in Lightning components under specific, well-defined conditions that meet security review criteria. **When Acceptable:** 1. **Namespace Restriction**: The component is **not exposed outside its namespace** 2. **Limited Visibility**: Its visibility is **limited to pages owned by the namespace** 3. **Controlled Usage**: Used exclusively within specific, controlled scenarios (e.g., forms pages within the namespace) **Security Review Criteria:** **General Restriction**: These properties are generally not allowed because components are reusable and can be placed anywhere in the app. Using `fixed` or `absolute` positioning could obfuscate other components or make a page unusable. **Exception Criteria**: These properties may be used if: - The component is **not exposed outside its namespace** - Its visibility is **limited to pages owned by the namespace** - The component is not designed for shared pages or external applications **Examples of Acceptable Use:** - A progress bar UI component fixed to the top of a page, used only on specific forms within the namespace - Components used exclusively within the namespace's forms pages - Self-contained components not intended for global accessibility **App Builder Considerations:** - Position:absolute CSS properties in Aura components are not generally acceptable for App Builder availability - Exception exists if the component is not exposed outside of the namespace and visibility is limited to pages owned by the namespace - If the component is exposed or used on shared pages, position:absolute is not allowed as it could obfuscate other components **Documentation Requirements:** - Clearly document the intended use and scope of the component - Specify that it is designed for specific use cases within the namespace - Verify the component's implemented interfaces to confirm its usage scope - Ensure the component does not interfere with shared pages or other applications
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Question
When is absolute or fixed positioning acceptable and what are the security review criteria?
Recommended Answer Update
Absolute or fixed positioning is acceptable in Lightning components under specific, well-defined conditions that meet security review criteria. **When Acceptable:** 1. **Namespace Restriction**: The component is **not exposed outside its namespace** 2. **Limited Visibility**: Its visibility is **limited to pages owned by the namespace** 3. **Controlled Usage**: Used exclusively within specific, controlled scenarios (e.g., forms pages within the namespace) **Security Review Criteria:** **General Restriction**: These properties are generally not allowed because components are reusable and can be placed anywhere in the app. Using `fixed` or `absolute` positioning could obfuscate other components or make a page unusable. **Exception Criteria**: These properties may be used if: - The component is **not exposed outside its namespace** - Its visibility is **limited to pages owned by the namespace** - The component is not designed for shared pages or external applications **Examples of Acceptable Use:** - A progress bar UI component fixed to the top of a page, used only on specific forms within the namespace - Components used exclusively within the namespace's forms pages - Self-contained components not intended for global accessibility **App Builder Considerations:** - Position:absolute CSS properties in Aura components are not generally acceptable for App Builder availability - Exception exists if the component is not exposed outside of the namespace and visibility is limited to pages owned by the namespace - If the component is exposed or used on shared pages, position:absolute is not allowed as it could obfuscate other components **Documentation Requirements:** - Clearly document the intended use and scope of the component - Specify that it's designed for specific use cases within the namespace - Verify the component's implemented interfaces to confirm its usage scope - Ensure the component doesn't interfere with shared pages or other applications
Reasoning
The FAQ content is technically accurate and well-structured. I made minor improvements to enhance readability and flow: (1) Changed "that it is designed" to "that it's designed" to match the conversational tone guidelines, (2) Changed "does not interfere" to "doesn't interfere" for consistency with contraction usage, and (3) Removed the category/subcategory labels at the end as they appear to be metadata rather than content for FAQ users. No security rules were selected because this FAQ addresses CSS positioning practices and UI security concerns that are not covered by the available security scanner rules. The provided rules focus on Apex security, authentication, data protection, and code vulnerabilities, but none specifically address CSS positioning properties or clickjacking prevention through component design restrictions. The FAQ's security guidance about namespace restrictions and component exposure limitations represents organizational security practices rather than code-level security rules that would be detected by automated scanners.