# Guideline 4.4.2 - Design: Safari Extension Requesting Overly Broad Website Access

**Guideline:** 4.4.2 · **Store:** Apple App Store · **Severity:** medium · **Fix difficulty:** medium · **Typical turnaround:** 2-8 hours

Canonical URL: https://appstorereject.com/rejections/apple/4/guideline-442-design-safari-extension-requesting-overly-broad-website-access

## Description

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.

## Common variations

- Safari extension requests access to all websites unnecessarily
- Extension website access is broader than required for its functionality
- Extension should only request access to necessary domains
- Overly broad website access raises privacy concerns
- Extension permissions exceed what is needed for stated features

## Example rejection email

```
Guideline 4.4.2 - Design - Extensions

Your Safari extension requests access to all websites, but this level of access does not appear to be necessary for the extension's stated functionality. Safari extensions should only request access to the websites where they provide features.

Requesting overly broad website access raises privacy and security concerns, as extensions with this access can read and modify content on any webpage the user visits.

Next Steps:
Please revise your extension's website access permissions to only include the domains necessary for its core functionality. If broad access is essential, explain why in the Review Notes and ensure users are clearly informed about the extent of website access.
```

## Resolution steps

## Quick Assessment
- **Risk level:** Medium
- **Resolution path:** Narrow website access or justify broad access
- **Typical turnaround:** 2-8 hours

## The Fix

### If you CAN narrow access:
01. **Identify required domains** — List every website where your extension provides functionality. Be specific — not 'shopping sites' but the actual domains.

02. **Update Info.plist** — Set `SFSafariWebsiteAccess` > `Level` to `Some` and populate `Allowed Domains` with only the necessary domains.

03. **Use domain matching patterns** — Use wildcards judiciously: `*.amazon.com` is fine if you need all Amazon subdomains, but don't use `*` for all domains.

04. **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:
01. **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.'

02. **Add user-facing privacy disclosure** — Before the user enables the extension, explain what data is accessed on each page and how it's used.

03. **Implement content script specificity** — Even with broad access, only inject content scripts when needed. Use `declarativeNetRequest` for content blocking instead of active page scripts.

04. **Minimize data collection** — Don't send page URLs or content to your servers unless essential. Process locally.

## Prevention
- Start with the narrowest possible access and expand only as needed
- Use `Some` access level with explicit domain lists by default
- Document your access justification before submission
- Consider whether a content blocker (which uses `declarativeNetRequest` and doesn't read pages) is sufficient for your use case

## Appeal guidance

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 examples

**Before:** Price comparison Safari extension requests 'All Websites' access but only provides functionality on 50 specific shopping domains
**After:** Extension's SFSafariWebsiteAccess Level changed to 'Some' with Allowed Domains listing the 50 specific shopping sites, extension gracefully deactivates on non-shopping pages
**Why it works:** Extensions must use the narrowest access scope possible. If you only work on 50 sites, don't request access to all sites.

## Common questions

**Can you appeal a 4.4.2 rejection?**

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.

**How long does this typically take to fix?**

Typical turnaround is 2-8 hours (difficulty: medium). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=guideline-442-design-safari-extension-requesting-overly-broad-website-access*