Guideline 4.4.2
Guideline 4.4.2 - Design: Safari Extension Requesting Overly Broad Website Access
Our Take
Apple is rejecting your Safari extension because it requests access to more websites than necessary for its stated functionality. Safari extensions must follow the principle of least privilege — requesting access only to the specific domains where the extension provides value, not blanket access to all websites. This rejection commonly hits ad blockers, productivity extensions, and content modification tools that request 'All Websites' access when they could function with access to a narrower set of domains. Apple's concern is both privacy (extensions can read page content) and security (broad access increases attack surface). The reviewers check your extension's SFSafariWebsiteAccess configuration in the Info.plist. If your Level is set to All but your extension's functionality only applies to specific sites (e.g., a coupon finder that only works on shopping sites), Apple will reject it. The fastest compliant path is to restrict your Allowed Domains to only the domains where your extension actually provides functionality. If your extension genuinely needs broad access (like a password manager or accessibility tool), you need to justify it clearly in your Review Notes and privacy disclosures.
Resolution Guide
Identify required domains
List every website where your extension provides functionality. Be specific — not 'shopping sites' but the actual domains.
Update Info.plist
Set SFSafariWebsiteAccess > Level to Some and populate Allowed Domains with only the necessary domains.
Use domain matching patterns
Use wildcards judiciously: *.amazon.com is fine if you need all Amazon subdomains, but don't use * for all domains.
Test the restricted configuration
Verify your extension activates only on allowed domains and handles non-allowed domains gracefully (no errors, no broken UI).
### If you NEED broad access:
Justify in Review Notes
Explain exactly why every webpage needs to be accessed. Examples: 'Password autofill requires page access to detect login forms on any website,' or 'Accessibility reader must reformat content on all pages.'
Add user-facing privacy disclosure
Before the user enables the extension, explain what data is accessed on each page and how it's used.
Implement content script specificity
Even with broad access, only inject content scripts when needed. Use declarativeNetRequest for content blocking instead of active page scripts.
Minimize data collection
Don't send page URLs or content to your servers unless essential. Process locally.
Prevention
Some access level with explicit domain lists by defaultdeclarativeNetRequest and doesn't read pages) is sufficient for your use caseExample Rejection Email
Consider Appealing
Appeal if your extension genuinely requires broad access (password managers, accessibility tools, content blockers). Explain the technical reason each visited page needs to be accessed and reference your privacy disclosures. If access can be narrowed, narrow it and resubmit.
Before & After
Price comparison Safari extension requests 'All Websites' access but only provides functionality on 50 specific shopping domains
Extension's SFSafariWebsiteAccess Level changed to 'Some' with Allowed Domains listing the 50 specific shopping sites, extension gracefully deactivates on non-shopping pages
What changed: Extensions must use the narrowest access scope possible. If you only work on 50 sites, don't request access to all sites.
Community Solutions · 0
Sign in to share your solution.
More Guideline 4 (Design) rejections
- Guideline 4.0 - Design: App Does Not Include iOS Features
- Guideline 4.0 - Design: App Looks Like a Website
- Guideline 4.0 - Design: Apple Pay Button Not Following Guidelines
- Guideline 4.0 - Design: Blurry Icons or Low-Resolution Assets
- Guideline 4.0 - Design: Broken Layout on iPad
- Guideline 4.0 - Design: Content Clipped by Notch or Safe Area