Salesforce Winter ’27 gives Experience Cloud administrators a useful new signal: warning icons in the Guest User Sharing Rule Access Report now identify fields that may expose personal information to unauthenticated visitors.

Treat those icons as the beginning of an investigation, not the end of one.

That distinction matters because public Experience Cloud access is a live security concern. In March 2026, Salesforce Security reported that threat actors were mass-scanning public sites and could extract CRM data when guest-user permissions were configured too broadly. Salesforce said the activity arose from customer configuration, not an inherent vulnerability in the platform.

For healthcare organizations, insurers, and nonprofit foundations, the operational stakes are high. Public sites may support provider searches, claims or service intake, grant applications, donor journeys, knowledge access, appointment requests, and case submission. Restrict access too little and data can become visible without authentication. Restrict it carelessly and a critical public service can stop working.

The right response is a controlled audit of the complete anonymous data path, followed by tested remediation and durable monitoring.

What changed in Winter ’27?

The Guest User Sharing Rule Access Report already helped administrators review objects, records, and fields made available through guest-user sharing rules. Winter ’27 adds a warning icon beside fields that Salesforce identifies as potentially exposing personal information. Examples can include address, contact, and revenue-related fields.

The signal is useful because it helps teams prioritize review. It does not make the access decision for them. A flagged field is not automatically evidence of a breach or even an incorrect configuration. Conversely, an unflagged field is not proof that its value is safe to publish in your organization’s context.

Salesforce’s own documentation says only the customer knows the site’s business requirements. That means the security decision must connect technical reachability to data meaning and a documented public-use case.

Why the native report is not a complete security assessment

The report provides valuable visibility, but Salesforce documents important boundaries:

  • Record counts above 10,000 are approximate and can skew low.
  • Several objects are omitted from the report’s object counts, including `EmailMessage`, `Contact`, `CaseComment`, `Task`, `Note`, and `AccountContactRelation`.
  • The report evaluates access associated with guest-user sharing rules; it does not replace review of profiles, field-level security, Apex, flows, APIs, site visibility settings, or self-registration.
  • A warning identifies potential personal information. It does not determine whether the exposure is intended, permitted by organizational policy, or appropriate for a specific public workflow.

A clean-looking report can therefore create false confidence if it is treated as an exhaustive scanner. Use it as one evidence source inside a layered assessment.

Audit the four layers of guest access

Salesforce describes Experience Cloud access as four sequential layers: object access, record access, field-level security, and field-value masking. A robust review should prove the expected result at each layer.

1. Inventory every public site and business journey

Begin with an inventory of Aura, LWR, Visualforce, Salesforce Sites, and any custom public entry points in each org. For every site, record:

  • The business owner and technical owner
  • Whether anonymous access and self-registration are required
  • The pages, forms, search features, files, and APIs available before login
  • The objects and fields each journey is expected to read or create
  • The Apex classes, flows, Lightning components, integrations, and managed packages involved
  • The data classifications and retention expectations that apply

Do not start by asking, “Which permissions can we remove?” Start by defining the smallest legitimate public service. That becomes the expected state against which configuration and test results can be compared.

2. Review effective object and record access

Run the Guest User Sharing Rule Access Report for every site, not just the highest-traffic portal. Review every row and investigate each object that contains records accessible to a guest.

Then examine the relevant guest profile, permission sets, permission-set groups, external organization-wide defaults, and guest-user sharing rules. A sharing rule should have a current owner, a specific business justification, narrow criteria, and a test that proves both allowed and denied cases.

Salesforce recommends private external defaults and least privilege. Guest sharing rules grant read access without login credentials, so a broad criterion can make every matching record available to anyone who can reach the site.

For the objects omitted from the native report’s counts, perform a separate configuration and effective-access review. Do not infer zero exposure from a missing number.

3. Trace fields through configuration and code

Field exposure is not only a page-layout question. Review field-level security and the fields returned by custom Apex, flows, components, GraphQL or REST endpoints, integrations, and managed packages used by the public experience.

Pay particular attention to `@AuraEnabled` methods, public APIs, classes that run without sharing, dynamic queries, relationship traversal, file access, and error responses that may disclose record details. Salesforce advises disabling guest access to public APIs and the guest profile’s API permission unless the business process explicitly requires it.

The Winter ’27 warning icon helps prioritize fields, but the final decision should also consider organization-specific sensitivity. A foundation may regard applicant affiliations and grant status as sensitive. A health insurer may need to protect member, provider, claim, and authorization context. A healthcare organization may need to separate public directory information from patient or appointment data. These are operational classifications, not conclusions the icon can make.

4. Prepare Independent Guest Field Masking before Spring ’27

Salesforce plans to enforce the “Conceal Personal Information Fields from Guest Users” release update in Spring ’27. The change creates a dedicated `Guest_PersonalInfo_EPIM` field set for unauthenticated guests, while `PersonalInfo_EPIM` continues to govern authenticated portal users.

The separation is valuable: an organization can conceal more User fields from anonymous visitors without unnecessarily changing the authenticated portal experience. But activation still deserves regression testing. Salesforce notes that masked fields used by Apex, flows, or UI components can return null or blank values and affect site behavior. Relationship fields and profile-photo or banner URLs are examples of dependencies that may need deliberate handling.

Inventory those dependencies now. Activate and configure the update in a representative sandbox, test the anonymous and authenticated experiences separately, and retain the evidence before production enforcement.

Test from the outside, not only from Setup

Configuration review shows intent. Anonymous end-to-end testing shows behavior.

Build a compact test matrix for each public journey:

  • A permitted visitor can see exactly the intended public fields and records.
  • A visitor cannot enumerate adjacent records by changing an ID, filter, page parameter, search term, or API request.
  • A guest cannot reach data through an alternate component or endpoint that is hidden from navigation.
  • Create-only forms do not reveal the submitted record or another person’s record afterward.
  • Files, error messages, autocomplete results, and related lists do not disclose unexpected data.
  • Self-registration, if required, assigns the most restrictive intended access and does not convert public information into a broader authenticated session.
  • Authenticated portal users retain the functions they need after guest access is tightened.

Run tests in a sandbox first, but do not stop there. Environment-specific domain, sharing, package, and integration differences justify a controlled production verification using approved test data.

Treat monitoring and incident readiness as part of the control

Access reviews decay as teams add fields, automation, packages, and new portal journeys. Assign an owner and repeat the review after releases and material site changes.

Where licensed, Salesforce recommends reviewing Aura Event Monitoring logs for unusual queries, unfamiliar IP addresses, off-hours access, or objects that were not intended to be public. Logging is helpful, but Salesforce also cautions against relying on volume alone when investigating suspected exposure.

Maintain a response path that identifies who can deactivate a site or public access, preserve relevant logs, contact Salesforce Support, assess the data involved, and coordinate qualified security, privacy, and legal review. The plan should be tested before an incident, not invented during one.

A practical definition of “done”

An Experience Cloud guest-access review is complete only when the organization can show:

  • Every public site and anonymous journey has an accountable owner.
  • Every accessible object, record set, and field maps to a documented public-use case.
  • The native report’s limitations are covered by complementary configuration and code review.
  • Public APIs, visibility settings, self-registration, Apex, flows, files, and managed packages have been assessed.
  • Independent Guest Field Masking has been configured and regression-tested for both guests and portal users.
  • Tests prove intended access and denied access from an anonymous browser and relevant endpoints.
  • Monitoring, release review, and incident-response ownership are in place.

This evidence does not by itself establish regulatory compliance, nor does it prove that no historical access occurred. It does give leadership a defensible operational picture of current effective access and a repeatable way to keep it controlled.

Turn a release feature into an operating control

Winter ’27 makes potentially sensitive guest access easier to spot. The organizations that benefit most will not merely clear warning icons. They will connect the signal to business intent, layered permissions, custom code, external testing, Spring ’27 readiness, and continuous ownership.

Yuniq provides Salesforce consulting, implementation and customization support, testing, and managed services. If your organization needs to assess a customized Experience Cloud estate, prioritize remediation, and validate that public journeys still work after access is tightened, talk to Yuniq about a focused Salesforce guest-access review .

4. Publishing Notes

Suggested featured image

Concept: A clean editorial illustration of a public customer portal viewed through four transparent security layers labeled Object, Record, Field, and Masking. A small warning marker appears on one data field, while a verification checklist sits beside the portal. Use realistic enterprise UI motifs without reproducing the Salesforce interface or logo.

Suggested social post

Winter ’27 can flag fields that may expose personal information to Experience Cloud guest users. But the native report has documented blind spots, and a warning icon is not a complete access assessment. Our new guide explains how to audit the full anonymous data path, test legitimate portal journeys, and prepare for Spring ’27 guest-field masking without breaking service.

Source list

  1. “Jen’s Top Winter ’27 Release Features For Admins.” Salesforce Admins, October 5, 2026. https://admin.salesforce.com/blog/2026/jens-top-winter-27-release-features-for-admins
  2. “Admin Release Countdown: Get Ready for Winter ’27.” Salesforce Admins, August 6, 2026. https://admin.salesforce.com/blog/2026/admin-winter-27-release-countdown
  3. “Security and Sharing — Winter ’27 Release Notes.” Salesforce Help, Winter ’27. https://help.salesforce.com/s/articleView?id=release-notes.rn_experiences_sharing.htm&language=en_US&release=264&type=5
  4. “Protecting Your Data: Essential Actions to Secure Experience Cloud Guest User Access.” Salesforce Security, March 7, 2026; updated March 11, 2026. https://www.salesforce.com/blog/protecting-your-data-essential-actions-to-secure-experience-cloud-guest-user-access/
  5. “Review Guest User Object, Record, and Field Access for Sites.” Salesforce Help, accessed October 7, 2026. https://help.salesforce.com/s/articleView?id=platform.networks_guest_user_access_verification.htm&language=en_US&type=5
  6. “Best Practices and Considerations When Configuring the Guest User Profile.” Salesforce Help, accessed October 7, 2026. https://help.salesforce.com/s/articleView?id=sf.networks_guest_profile_best_practices.htm&language=en_US&type=5
  7. “Conceal Personal Information Fields from Guest Users (Release Update).” Salesforce Help, Winter ’27; accessed October 7, 2026. https://help.salesforce.com/s/articleView?id=release-notes.rn_experiences_conceal_pii_guests.htm&language=en_US&type=5
  8. “Configure Independent Guest Field Masking.” Salesforce Help, accessed October 7, 2026. https://help.salesforce.com/s/articleView?id=platform.users_personal_info_guest_field_sets.htm&language=en_US&type=5
  9. “Salesforce issues customer alert as ShinyHunters group claims Experience Cloud breach.” ITPro, March 10, 2026. https://www.itpro.com/security/cyber-attacks/salesforce-issues-customer-alert-as-shinyhunters-group-claims-experience-cloud-breach
  10. “Salesforce Services.” Yuniq, accessed October 7, 2026. https://yuniq.co/salesforce

Claims for human or subject-matter review

  • Confirm the final Spring ’27 enforcement date for each production instance in Salesforce Trust before publication; the release note specifies the release, not one global date.
  • Validate the current list of objects omitted from Guest User Sharing Rule Access Report counts immediately before publication because Salesforce Help can change between releases.
  • Have a Salesforce security architect review the audit and testing sequence against the organization’s actual Experience Cloud architecture, licenses, managed packages, and custom endpoints.
  • Have security, privacy, and legal specialists review any organization-specific statements about personal, health, insurance, applicant, donor, or regulated data. The article intentionally makes no legal or compliance assurance.
  • Verify Yuniq’s current service wording and CTA destination before publishing. Do not imply a Salesforce endorsement or guarantee that an audit proves the absence of historical access.