Security discussion: Unauthenticated /v1/* endpoints + proposed non-invasive mitigation

[shaoqing404]

Title
Security discussion: Unauthenticated /v1/* endpoints + proposed non-invasive mitigation

Body
Hi RAGFlow team, thanks for building such a solid project — we're actively evaluating it for deployment in a corporate intranet environment.

During our internal security assessment for intranet Docker deployment, we noticed that some endpoints (e.g. /v1/document/get and similar document-related APIs) can be accessed without authentication when the service port is exposed. This has already triggered alerts in our security scanning tools, and may lead to unintended data exposure (documents, metadata, or other resources depending on the deployment).

Our Use Case

We're deploying RAGFlow as a Docker-based service in our corporate intranet to support internal knowledge management workflows. As part of our security compliance process, we need to work with our security department to address vulnerabilities flagged during automated scans. While we understand the project is evolving quickly and there may be compatibility reasons (e.g. supporting <img> calls or other integration constraints) that led to relaxing auth on these endpoints, from a deployment standpoint this is a latent security risk: once the scanner detects an unrestricted port + unauthenticated sensitive APIs, it becomes difficult to pass internal review even if the project itself is excellent.

Questions (to understand the context)

1. Why was the Cookie-based authentication approach deprecated/disabled previously?
   (cc: @RAGFlow_TS_xjx and @虞礼瑞 for WCG 491 — I'm trying to understand the original trade-offs.)
2. Are there any planned directions for a minimal, backwards-compatible auth layer for document endpoints?

A non-invasive mitigation idea (Nginx + small proxy)

Given the codebase is under rapid development, we'd like to avoid invasive changes inside RAGFlow. A deployment-level mitigation could work like this:

1. POST /v1/user/login returns a successful response and includes auth information in response headers (e.g. Authorization appears at this moment).

2. A lightweight proxy service A sits in front of RAGFlow only for the login response path:

   • It captures the auth token from the login response (e.g. Authorization).
   • It rewrites the response by adding Set-Cookie: token=<...>; HttpOnly; Secure; SameSite=... (configurable).

3. Then Nginx enforces that all /v1/* (or at least document-related endpoints) require a valid cookie (or equivalent), and requests without cookie get 401.

4. The cookie presence/validity can be verified via an existing endpoint like /v1/user/info (auth probe).

In other words:

We only change Nginx configuration + add a tiny proxy, and do not require modifying RAGFlow's internal auth logic during this fast-moving phase.

This also fits stricter enterprise network rules: containers don't directly expose the raw service port (e.g. 9380), but are reachable only via Nginx forwarding.

Why this helps enterprise deployment

• Reduces the chance that a scanner flags "unauthenticated sensitive APIs".
• Keeps RAGFlow core untouched (non-invasive).
• Still allows compatibility with <img> or other clients that can't easily add custom headers, by relying on cookies.
• Aligns with corporate security policies that require all services to be behind reverse proxies.

What we've validated so far

• The Authorization header is correctly returned after POST /v1/user/login
• The /v1/user/info endpoint can serve as an auth probe
• Cookie-based auth works well with Nginx auth_request module
• Docker containers can be configured to not expose port 9380 directly, relying on Nginx forwarding

Open to feedback

This is a working idea, and we'd love to hear:

• Whether the team sees any pitfalls with this approach (especially around token lifecycle / expiry / refresh)
• Whether there is a preferred minimal path toward restoring/standardizing auth for these endpoints
• If this approach aligns with RAGFlow's roadmap, we're happy to contribute a reference implementation (Nginx config + lightweight proxy) that other enterprise users could leverage

ps：We have implemented a straightforward approach. If you're interested, feel free to apply for access and read the details at:

Thanks again — our goal is to help make RAGFlow easier to deploy safely in real-world enterprise environments while respecting the project's development velocity and architectural decisions.

[Clint-chan]

support

[shaoqing404]

I've also attached a Chinese explanation of the mechanics.

[KevinHuSh]

Good suggestions.
What about the embeded iframe of chat dialog, in which scenario people do not need to login?

[yingfeng]

Only this API /v1/document/get has security issue. Because it's used for the embedded iframe shared by the user which means the third party systems can directly show the chat together with the document preview if the author of the dataset share the page.
I believe we need a more thorough solution that not only secures the API but also ensures a smooth experience for users accessing shared chat pages.

[shaoqing404]

Thanks both for the thoughtful replies — I think this helps clarify that we’re actually discussing product-level access semantics, not just API auth mechanics.

About the embedded iframe scenario (reply to @KevinHuSh )

For the iframe case where users are not required to log in:
from an enterprise / intranet deployment perspective, this is less a technical exception and more a deliberate product contract.

If an embedded chat dialog (with document preview) is accessible without login, then effectively:

access is still being granted,

just not via user identity, but via some form of shared capability.

In internal environments, “no login” is acceptable only if the resource is explicitly defined as:

public,

or shared with a clearly scoped, auditable, and revocable mechanism.

Otherwise, unrestricted iframe access is indistinguishable from content leakage during security review.

About /v1/document/get being used for sharing (reply to @yingfeng )

I agree this endpoint is special and tied to the shared iframe experience.
However, that actually strengthens the case for a more explicit model.

Right now, the security assumption seems to be:

“If a dataset author shares a page, the document API can be open.”

From a risk-control standpoint, this becomes much clearer if reframed as:

sharing issues a scoped share token (or equivalent),

that token is explicitly intended for iframe / third-party embedding,

/v1/document/get validates that capability, rather than being globally unauthenticated.

This way:

the API is not “open” by default,

the iframe experience remains smooth,

and enterprise deployments can clearly explain why a given request is allowed.

Why I proposed the Nginx + proxy approach

The original suggestion was meant as a non-invasive deployment-layer workaround, because:

the codebase is evolving fast,

and enterprises often need something they can deploy now without forking core logic.

Long term, a first-class “share access” mechanism (token, scope, expiry) inside RAGFlow feels like the clean solution.
Short term, many teams will otherwise be blocked at security review, even if they never plan to expose iframe sharing at all.

Happy to continue the discussion — I think we’re circling the same goal:
secure-by-default, with explicit opt-in for sharing scenarios.

[yingfeng]

We've got some solution and will apply it to the repo asap. All API requests should not be accessed without authentication.

[shaoqing404]

We've got some solution and will apply it to the repo asap. All API requests should not be accessed without authentication.

只有官方才能做的更好更快！很高兴能参与谈论，新年快乐。

[yingfeng]

We've got some solution and will apply it to the repo asap. All API requests should not be accessed without authentication.

只有官方才能做的更好更快！很高兴能参与谈论，新年快乐。

Latest 0.24 has fixed this issue already. All APIs are required to be authenticated at first.

[shaoqing404]

*邮件总结 (Email Summary):* Hi Yingfeng and Team, Thank you for the fast response and for implementing the fix! We are pleased to hear that version 0.24 has already addressed this security issue, and we will actively verify these changes on our end. Given that the Chinese New Year is approaching, are there any plans to roll out a new minor version, such as 0.24.1, before the holiday? Best regards, 郑迟 Yingfeng ***@***.***> 于 2026年2月11日周三 14:51写道：

…

We've got some solution and will apply it to the repo asap. All API requests should not be accessed without authentication. 只有官方才能做的更好更快！很高兴能参与谈论，新年快乐。 Latest 0.24 has fixed this issue already. All APIs are required to be authenticated at first. — Reply to this email directly, view it on GitHub <#13015 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A44KAOUSB4GB77FTGUJ7OMD4LLGNZAVCNFSM6AAAAACUB2VOZWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZWGQ4TOMA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[yingfeng]

As the Chinese New Year approaches, we have no plans to release 0.24.1. Version 0.24 is not a release with significant updates. Moving forward, our focus will be on evolving toward 0.25.