What must stay private when documentation sits behind a login?

How we researched this

We inspected original product documentation, OWASP guidance, RFC 9111 and a dated BookStack security release on November 8, 2026. We compared the scope of the controls they describe and developed a fictional partner-portal review matrix. We did not test vendor systems, scan customer sites, access private repositories or measure breach rates. Product statements are documented behavior or provider assertions, not independently verified security outcomes.

What does private mean for this documentation?

Start with a sentence a reader and an administrator can both understand: “Only current members of the partner's implementation team may read these integration instructions and their supporting files.” That is more specific than “the docs have SSO.” It identifies an audience, a set of resources and a condition that can change.

OWASP distinguishes checking identity from checking whether an action is allowed. Its authorization guidance recommends least privilege, denying access by default, permission checks on every request and protection for static resources. It also warns against making client-side logic the decisive access check. OWASP authorization guidance

For a documentation owner, the next step is to define what the audience restriction includes. A product logo might intentionally be public. A screenshot containing a partner's configuration might not be. A public release note can mention that a feature exists while the implementation guide remains restricted. Those choices are not inherently contradictory, but they must be explicit.

This is a proposed requirements table, not a product feature comparison. The evidence column is intended to replace ambiguous sales-demo answers with something a team can review.

Be precise about actions too. Reading a page, editing it, downloading an attachment and exporting a whole book are different operations. A reader might be allowed to view a guide but not generate a bulk export. An editor may need draft access without the authority to change the audience. Write those distinctions before creating the roles, so the roles serve the intended policy rather than define it accidentally.

Why do noindex and robots.txt not make a page private?

Google's guidance says a noindex rule can keep content out of Google Search while leaving it accessible to visitors who have a link. For confidential content, it directs owners toward password protection. That distinction is about serving the content, not just how easily someone discovers it. Google sharing controls

Google separately explains that robots.txt controls crawler access and cannot enforce crawler behavior. A disallowed web-page URL can still appear in results when linked elsewhere, even without Google fetching its contents. Google robots.txt guidance

The practical decision is whether the content may be retrieved by an ordinary visitor. If the answer is yes, hiding it from search may be a valid distribution choice. If the answer is no, search settings cannot carry the audience restriction.

Consider a fictional partner guide sent by email before a launch. The team might want the guide reachable by anyone with the link and absent from public search. That can be an intentional low-friction sharing policy. It becomes a problem when the same team promises that only named partner employees can read it. A forwarded link now tests a different promise.

Keep three acceptance questions separate:

• Can an unauthorized visitor obtain the content?
• Should a search engine index or display the URL?
• What information may appear in a result, link preview or public navigation label?

A passing answer to one is not evidence for the others. A page missing from search results might still be public, while a correctly protected page can still have a deliberately public title on a marketing site.

If formerly public material becomes restricted, record that history. Changing the current access policy does not establish that every earlier copy or reference has disappeared. Decide what should happen to the original URL and communicate the change to legitimate readers. Do not treat a reduced search footprint as proof that the distribution history has been reversed.

Do the page and its files follow the same rules?

BookStack's upload documentation provides a concrete reason to ask. Its default local storage serves images publicly. The local_secure option requires a login for images when public access is disabled; local_secure_restricted instead checks access to the item the image was uploaded to. The documentation also notes performance and usability tradeoffs, including copied-page images retaining the original page's access relationship. BookStack file storage

BookStack's attachment guide states that access follows the view permissions of the page to which the attachment was uploaded. This is a separate documented path from default image serving. BookStack attachments

The table summarizes configuration choices, not a finding that a particular installation is misconfigured. BookStack file storage

Now apply the question to a fictional deployment guide. It contains explanatory text, a screenshot of configuration values and a downloadable example file. Protecting the text while intentionally publishing a generic illustration may be fine. Publishing the configuration screenshot would violate this example's policy even if the page displaying it required a login.

Build an inventory around what each file reveals, not its extension. The same PNG format can hold a public logo or a confidential diagram. An attachment described as a “sample” can still contain names or values copied from a real environment. For testing, replace those with invented markers that can be recognized without using private information.

Ask how reused assets behave. If an image appears in both a restricted page and a public tutorial, which audience is intended? If a private page is copied into a shared collection, do its files inherit a new policy or retain their original one? A correct restriction can also create broken images for authorized readers. Your review needs to catch both overexposure and unnecessary denial.

The useful deliverable is a short resource map: page, file, storage location, intended audience and owner. It gives the administrator a way to investigate a mismatch without assuming that changing the page's visibility changed every dependent URL.

Can search reveal material the page will not open?

Algolia's API-key documentation distinguishes allowed operations from restrictions on data access. A search-only key permits searching; the documentation warns that exposed keys can be used to retrieve index content within their configured scope. It describes secured keys that inherit their parent key's restrictions and can be scoped more narrowly. Algolia API keys

Its user-restricted-access guide provides a record-filtering approach for limiting results by user. This is an implementation pattern to configure, not a claim that every frontend search integration already enforces a reader's permissions. Algolia user-restricted search

For the proposed review, treat a search result as content in its own right. A blocked article can still have a sensitive title, excerpt, filename or section heading. Decide whether unauthorized readers may learn that the article exists. That decision may differ between a public partner-program overview and an internal incident runbook.

Use two separate questions:

1. Which records are available to the search request?
2. Which returned fields may be shown to this reader?

Hiding a result in the interface does not establish that its text was withheld from the response. Similarly, checking the destination page only after a result is clicked does not establish that the excerpt was permitted. Inspect the actual response in a controlled test as well as the visible result.

Include static search files in the inventory if the site uses them. If a file containing restricted text is intentionally delivered to the browser, the reader has already received that text, regardless of whether the search box displays it. A separate public index may be appropriate; the choice depends on the intended audience and how updates are published.

Apply the same proposed rule to AI retrieval: the material made available to the answer system should match the requesting reader's permitted scope. Test invented restricted phrases through the answer, its citations and any suggested follow-up links. Do not count a reassuring answer as evidence that the underlying retrieval boundary was enforced.

This report does not test an AI search product or measure leakage frequency. The contribution is an acceptance question that connects the page policy to every way the site returns information about that page.

What changes when a page becomes a draft or is deleted?

On October 20, 2026, BookStack published security release v26.09.2. Its advisory describes fixes for comments on deleted pages remaining visible through the API while the pages were in the recycle bin, and for attachment modification permissions while parent pages were drafts. The latter involved users who already had attachment update or delete permissions. These are reported fixed issues, not claims about an unpatched system we tested. BookStack October release

The cases make a specific addition to a docs evaluation: include content states. Published pages are only one part of a publishing workflow. Drafts, revisions, deleted items and restored items can have different intended audiences.

Our proposed review follows one synthetic guide through those states. Give it a harmless unique marker and a supporting image. Define what a normal reader, an editor and an administrator may see at each stage. Then check the ordinary interfaces and the corresponding API or download routes used by the application.

These are suggested cases, not results. A team may choose a different policy, but each expected outcome needs to be recorded before the test.

Do not turn a public security advisory into a product ranking. A disclosed and fixed issue gives concrete regression cases. It does not supply a denominator for how often installations were affected, how many people accessed anything, or whether a competing product performs better. Those questions would require different evidence.

For a self-hosted evaluation, include the deployed version in the record. A feature description and an update advisory answer different questions: one describes the intended control, while the other describes a correction made in a particular release.

What should happen after a reader loses access?

GitBook's authenticated-access guide says the configured authentication provider handles who can access published content. Its built-in logout URL ends a visitor's GitBook session. That tells an evaluator where part of the integration lives; it does not by itself specify the timing of every organization-membership change or previously issued credential. GitBook authenticated access

GitBook's Security FAQ also states that access to private content through its CDN is validated by its application servers. This is a provider statement, not a test we performed. It is a useful example of the question to ask when content is served through more than one layer. GitBook Security FAQ

Separate future delivery from copies already received. Removing someone from a group can change what the server will return next. It cannot establish that a PDF they downloaded yesterday, a screenshot or a pasted excerpt no longer exists. Set expectations accordingly when choosing to enable exports.

HTTP caching adds another distinction. RFC 9111, published in June 2022, says an unqualified private response directive prevents shared-cache storage while permitting private-cache storage under its rules. The no-store response directive applies to both private and shared caches, but the RFC explicitly says it is insufficient by itself to ensure privacy. These are cache controls, not a user-permission model. RFC 9111

For the fictional partner portal, define a removal deadline and identify which systems must honor it. Use a chosen deadline that matches the deployment's documented behavior; do not invent an instant-revocation guarantee because the admin screen updates instantly.

Test at least two conditions. First, remove the reader while their existing session is open, then make a new request. Second, attempt a fresh sign-in after removal. Record both results and their timestamps. If the portal issues temporary search or file credentials, include their documented lifetime and the relevant revocation mechanism.

Check that an authorized reader still succeeds after the change. A test that blocks everyone can look reassuring from the removed reader's browser while making the documentation unusable for the remaining team.

For a formerly public resource, review serving configuration and cache behavior together. Keep historical copies and current authorization as separate findings. That distinction makes an incident or migration report more accurate than a blanket claim that the material is now “completely private.”

How can a team test the boundary without using real private content?

Create a small synthetic collection in an environment you own and are authorized to test. Give each page and file a distinct invented marker. Use test accounts with deliberate roles rather than a single administrator account. Do not use actual customer documents to make the test more realistic.

For this example, define four reader states: anonymous visitor, permitted member, member of another organization and removed member. Define six resources: page body, image, attachment, search result, export request and historical revision. Four states multiplied by six resources gives 24 planned observations. None were executed for this report. This is a fictional plan, not a benchmark score or a minimum certification requirement.

Write down the expectation for each of the 24 cells. If export is intentionally unavailable to ordinary members, mark that cell as denied rather than counting it as a defect. If the site has no revision-viewing feature, replace that resource with another relevant path and describe the change.

Use distinct browser contexts so an administrator's session does not contaminate the anonymous check. Open links directly as well as through navigation. For downloaded files, confirm whether the returned bytes contain the invented marker. For search, inspect results and response data. Record the actual status and behavior rather than assuming every correct denial must use the same HTTP code.

Repeat selected observations after a policy change. The initial 24 cells cover one configuration at one time; they do not cover every membership transition, browser cache state or storage backend. Add cases where the resource map shows a separate delivery path.

The evidence record should include:

• The version, deployment and configuration tested.
• The reader role and resource, without real credentials.
• The intended outcome and the observed response.
• The timestamp relative to any permission change.
• The result for an authorized reader after the same change.
• The owner of any unresolved mismatch.

This proposed plan is designed to make a review concrete. It cannot show that no other access-control defect exists, and it should not be presented as a replacement for a broader security assessment.

What should you ask before choosing a private docs platform?

Ask for a demonstration of the audience promise using your synthetic collection. A successful login is the beginning of that demonstration. Follow it with a direct file request, an unrelated member's search and an access-removal test.

Request a resource-by-resource explanation of what the platform protects by default and what depends on configuration. Ask whether images, attachments, generated exports, API responses and old revisions use the same audience rules. When a vendor says “SSO supported,” ask how organization or group membership becomes permission to read a particular collection.

Discuss failures as well as the happy path. If the identity provider is unavailable, what does a reader receive? If a membership update has not propagated, where is that visible? If a page is restored from a recycle bin, which policy applies? Get the relevant documentation and identify who owns each part of the configuration.

Keep public product documentation and restricted internal knowledge separate in the decision when their needs differ. A public publishing workflow can be excellent for onboarding customers without being the right place for confidential runbooks. This report does not assert that Docsio implements the private-access architecture described here.

The final output should be a short, reviewable agreement about audience, resources, actions and timing. Attach the observed results and unresolved gaps. That gives a team something more useful than a checkbox beside “private docs”: a defined promise about what readers can receive, and evidence about where that promise was tested.

Limitations

This is a research synthesis and proposed acceptance plan, not a penetration test, compliance assessment or vendor ranking. Behavior depends on version, configuration, identity provider and deployment. Public documentation can omit implementation details. The fictional test counts measure planned coverage only. Revoking future access does not establish that copies already obtained by an authorized reader have been removed.