WEBSITE PLANNING

Decide Which Portal Information Should Be Public

Classify portal information by audience before deciding which pages belong in public search.

Separate public usefulness from customer confidentiality

A public guide can explain how a service works. A customer invoice, private attachment or project conversation serves a different audience. List the actual data each screen and download exposes rather than classifying only the page title. A harmless-looking status page can still disclose customer information through its underlying request.

Use a simple audience exercise

In a hypothetical portal, the service FAQ is public, a customer’s project timeline belongs to that customer and assigned staff, and internal pricing notes belong to designated staff. Write those decisions before building navigation. If a page mixes public and private information, consider separate views rather than assuming one visibility switch fits the whole page.

Enforce the boundary beyond the interface

OWASP recommends denying access by default and validating permissions on every request. Hiding a menu item or adding noindex does not enforce the customer boundary. Include files, exports and API responses in the access review. A user who knows another record’s address should not gain access merely because the link was predictable.

Review both allowed and denied behavior

Use authorized sample accounts representing different customers and staff roles. Verify the expected public view, the correct customer view and the denied cross-customer request. Keep production personal data out of demonstrations. Record who approves each exception and when it will be reviewed. Public SEO improvements should apply to the public content, while private customer operations retain their own access requirements.

Apply this to your website

Bring the relevant URL and a description of the decision to request a scoped website review. Do not send passwords or private customer records. The primary reference is the linked technical guidance.