NSF Files Accessible via COM or Java APIs Despite ACL Restrictions

Subject: Security Concern: NSF Files Accessible via COM or Java APIs Despite ACL Restrictions

Product Version: HCL Domino 11.0.1 FP9 / Notes Client 11.0.1 FP9

Issue Summary:

In our environment, Domino NSF databases are configured with Default access set to Author. However, we have identified that other programming languages (e.g., VBScript, C#, or Java) can still access and read NSF documents directly using:

  • Windows COM APIs (e.g., CreateObject("Notes.NotesSession"))
  • Java Notes.jar APIs (e.g., NotesFactory.createSession())

These programmatic methods bypass UI-level design restrictions and allow document-level access without triggering formula-based controls (e.g., hide-when, readers fields).

Risk:

  • Sensitive data leakage is possible if NSF files are copied or cached locally.
  • Reader/Author field enforcement can be bypassed.
  • Design-hidden databases can still be accessed using COM or Java APIs.
  • Domino security model assumes trusted execution context, which is not always true on endpoint machines.

A built-in method to restrict or block COM/Java-based access per database is urgently needed to prevent unauthorized programmatic reading of Domino data.

Hi Goodman,

The Author level ACL access will allow you to read any documents that the user created. If the users are accessing other documents other than they authored then this would be an issue. Please open a case with us so we can look into that. When we access documents from the back end classes like the C API or Java, we bypass the UI-Level design like Hide/When formulas. The hide/when formulas should not be used to prevent access to data. Even if some data is hidden in the UI, this does not mean that the data can not access. If you look at the document properties and the fields tab you can see the data there. If we are wanting to protect the data then we should be using field level encryption and just give the secret encryption key to just those users that can access the data.

2 Likes

You should really look into “real” security in Domino applications.

Hide-When formulas are in no means a security feature. Even a normal user can “see” information that is simply hidden with Hide-When-Formulas by opening the properties box (Alt + Enter).

Being “Author” on a database means: everybody can see every document that is not protected by a reader field.

You get security by:

  • Secure every document with appropriate reader fields: Empty Reader field = Everybody can see it
  • Encrypt information that you want to protect from people who are allowed to read the documents
  • Set “Default” access to “No access” and explicitely give the desired users access to the database using groups
  • Author fields only prevent people with “Author” access from editing documents. They do NOT hide any information and therefor are weaker than reader fields (although they are added to reader fields if there exists at least one with an entry)
1 Like

Hello Paul,

Thank you for your reply and explanation regarding our reported issue. We understand that when accessing Domino data through backend methods such as the C API or Java API, UI-level design restrictions (e.g., Hide/When formulas) are bypassed, and that these formulas are not intended to prevent programmatic access to data. We also acknowledge that any data visible in the Document Properties → Fields tab can be read programmatically, even if it is hidden in the UI.

However, in our testing, we found that even when a database’s Default ACL access is set to Author, and the user has not created the target documents, it is still possible to read document content through COM or Java APIs. This behavior appears to differ from our understanding of the intended Author-level restrictions.

In real-world environments, due to the large data volume and the number of applications involved, it is not practical to implement Readers field controls on all sensitive fields—maintenance costs and complexity would be too high. We have also confirmed, using simple COM and Java test programs, that as long as the user has a valid Notes ID and the database ACL is set to Author, they can retrieve all documents in the database in bulk, bypassing both UI restrictions and Readers field enforcement. This indicates a protection gap in Domino’s current ACL model at the API level.

We agree that field-level encryption can protect sensitive data, but in our current environment, implementing it across all applications would require significant development and operational resources. Therefore, we still believe Domino should provide a database-level option to selectively block or restrict direct access via COM/Java APIs, to reduce the risk of unauthorized programmatic data retrieval.

Additionally, you suggested opening a formal case for further investigation. Could you please provide the proper process and required information format for case creation? For example, should we submit it via the support portal, and what details are mandatory—such as test logs, code samples, or server configuration screenshots?

We will follow your guidance to open a formal case and provide detailed reproduction steps and environment information to help clarify the issue and evaluate potential solutions.

Appendix – Minimal Test Code

VBScript (COM API) Example
Set session = CreateObject(“Notes.NotesSession”)
Call session.Initialize(“”) ’ Prompt for password
Set db = session.GetDatabase(“”, “test.nsf”)
If db.IsOpen Then
Set view = db.GetView(“vwAll”)
Set doc = view.GetFirstDocument()
Do Until doc Is Nothing
WScript.Echo doc.GetItemValue(“Subject”)(0)
Set doc = view.GetNextDocument(doc)
Loop
End If

Java Example (Notes.jar API)
import lotus.domino.*;

public class ReadAllDocs {
public static void main(String args) {
try {
Session session = NotesFactory.createSession(); // Uses local ID
Database db = session.getDatabase(“”, “test.nsf”);
View view = db.getView(“vwAll”);
Document doc = view.getFirstDocument();
while (doc != null) {
System.out.println(doc.getItemValueString(“Subject”));
Document tmp = view.getNextDocument(doc);
doc.recycle();
doc = tmp;
}
session.recycle();
} catch (Exception e) {
e.printStackTrace();
}
}
}

In both tests, the Notes ID used has only Author access to the database, yet all documents (not authored by the ID) are still retrievable.

Additional Clarification:
Regarding your comment that users can view data in the document properties and Fields tab, in our environment this is not possible. We have implemented design-hidden controls, so users cannot open document properties or view the Fields tab in the Notes Client UI. Therefore, the risk described is unrelated to UI-level access and is specifically about COM/Java APIs bypassing these restrictions.

Hi Goodman,
Here is a link on opening a case with support - How to create a support case - Customer Support

When opening a case the more information provided initially the faster we can get the case resolved. So make sure and include details on the version of Notes/Domino, Details on the environment, Business impact, a link to this post, the example code you provided here and a design only copy of the test.nsf so we can take a look and use it to reproduce the issue. Once the case is created you will be able to upload files to it.

Hi Paul,

Following up on our previous discussion regarding the potential security vulnerability in Domino R11.0.1 (Author-level access allowing retrieval of all documents via COM/Java APIs), I would like to inform you that we have formally submitted the report to HCL PSIRT.

The submission has been registered under case number CS1390993.

This submission includes:

  • Product details and version (Domino R11.0.1 FP9)
  • Vulnerability summary and security impact
  • Reproduction steps with VBScript and Java examples
  • Additional clarification that, in our environment, UI-level restrictions (design-hidden to prevent document properties/fields view) are already enforced, yet programmatic access still bypasses these controls.

We would appreciate it if you could help monitor the progress of this case and keep us informed of any updates from the PSIRT team.

Best regards,
Goodman.Chu
Formosa Plastics Group
Email Address1:goodman.chu@gmail.com
Email Address2:goodman@fpg.com.tw

Hi Paul,

Following up on our earlier discussion and the recent response from the support team regarding case CS1390993:

While the reply positions this as an enhancement request (referencing earlier case CS0516767 and idea DOMINO-I-2711), I would like to clarify why we believe this is in fact a security vulnerability that should be escalated to PSIRT for formal evaluation.

  1. Practical impact – In our environment, if a user possesses a valid Notes ID and has Author access to a Domino NSF without Reader field restrictions, they can programmatically retrieve all documents via COM (Notes.NotesSession) or Java (NotesFactory.createSession), bypassing all UI-level design restrictions such as hide-when formulas and property/field tab visibility.
  2. Contradiction with some product statements – Actual testing confirms that Author-level ACL can read documents not created by that user, contrary to the statement “Author level ACL access will allow you to read any documents that the user created.”
  3. Security and compliance risk – This behavior allows for bulk extraction of sensitive data, potentially violating privacy regulations (GDPR, local data protection laws).

Currently, we use design-level hiding to restrict access, so users cannot view document properties or field data from the Notes client UI. However, COM/Java back-end API access completely bypasses these safeguards.

We understand the current architecture does not differentiate between Notes client and COM/Java connections, but this is exactly why it should be treated as a security issue, not just a functional enhancement.

We can provide full reproduction steps along with VB and Java sample code used in testing.
Please advise on the process to ensure PSIRT receives and formally evaluates this case.

Best regards,
Goodman.Chu
Formosa Plastics Group
Email Address 1:goodman.chu@gmail.com
Email Address 2:goodman@fpg.com.tw

Dear Paul,

We have raised this security concern with the Support team(NO:CS1390993); however, their response indicates that they are unable to address this issue through their channel and suggested that we contact the Sales team for further escalation.

To recap the core issue:

  • Once a user authenticates with a valid Notes ID, they can use external programs (e.g., Java, COM, Python) to access and extract NSF data directly, bypassing UI-level controls.
  • This poses a significant security risk, and currently, Domino does not provide a method to restrict or monitor this type of access.

Could you please advise if there are any recommended measures or if escalation through Sales is the correct next step?

Thank you for your guidance.

Best regards,
Goodman.Chu

How can “Reader/Author field enforcement can be bypassed” ?

This sounds like a poorly designed database. Where security wasn’t considered during the design phase. To truly lock down documents from people you’d use reader fields and/or encryption.

Dear flyboytyler:

Thank you for sharing your perspective. We fully understand the importance of security considerations during the design phase, and we have implemented various measures to secure our applications at the UI and design levels.

However, our environment involves a very large user base and extremely high document update frequency. In our past experience, applying Reader fields for access control caused significant performance issues, including severe delays and inability for users to open documents via links in a timely manner.

This is why our current concern is focused on scenarios where, after Notes ID authentication, an external program (using COM, Java, or other APIs) can access and extract all data from an NSF database without opening the Notes client, effectively bypassing any UI-level security measures.

We are seeking an official recommendation from HCL on how to prevent this kind of data extraction approach, while still maintaining system performance for large-scale deployments.

Goodman.Chu

Dear Paul,

We previously raised this issue with HCL Support, but they confirmed it is considered a product feature and cannot be resolved via their channel.

However, this is a critical security concern:

  • Any authenticated Notes ID can use external programs (COM, Java, Python, etc.) to access and extract all NSF data without launching the Notes client.
  • This completely bypasses all UI-level and design-level security controls.

We have evaluated the recommended approach of using Reader fields, but in our environment, this is not feasible:

  • We manage a large user base with high-frequency data changes.
  • Prior implementation of Reader fields caused severe server delays, preventing users from opening linked documents and processing tasks.

This means the commonly suggested mitigation (Reader fields) does not solve the problem in real-world large-scale deployments.

We urgently request:

  1. Official guidance on how to prevent or restrict this type of external program access.
  2. If no existing solution, a clear roadmap or statement on planned enhancements to address this risk.

This vulnerability affects all current Domino versions and represents a significant compliance and data protection risk. We strongly urge HCL to prioritize this matter.

Best regards,
Goodman.Chu

I do not see this as a security vulnerability in the product, I see it as a lack of knowledge into how the product is architected. I think you have a misunderstanding of what the different Access Levels mean. The key take away here is security through obfuscation is not security.

Speaking to HCL sounds like the right approach for you though.

“This means the commonly suggested mitigation (Reader fields) does not solve the problem in real-world large-scale deployments.”
We have a DB that uses readers fields and has over 400,000 documents with no performance issues. I’d be interested to know what you consider “large-scale”?

Whilst I can’t agree that this is a “vulnerability” a “critical security concern” or “represents a significant compliance and data protection risk” I do think an ACL option to restrict API/COM access would be a good idea, similar to the “maximum internet name and password” option. You should post that idea here:

1 Like

Hello GlenUrban, thank you for your feedback and suggestions. Here’s our response:

1. On “Large Scale” Definition and Reader Field Issue

When we refer to “large scale,” our environment includes:

  • User base: Over tens of thousands of users
  • Applications: More than 1,000 apps, tightly integrated with ERP systems
  • Update frequency: Extremely high, with massive daily document changes

We have previously tested Reader fields for access control, but the results showed that frequent Reader field changes caused significant performance degradation, even preventing users from opening document links.
The root cause is that Reader field changes trigger massive index rebuilds and view refresh operations, which pose major risks in our high-volume and high-frequency update scenario.

Therefore, relying solely on Reader fields is not a feasible solution for us.


2. On ACL Option to Restrict API/COM Access

We strongly agree with your idea of introducing an ACL option to restrict API/COM access. This would significantly improve security, especially by preventing authenticated Notes IDs from extracting entire databases via external programs.
This suggestion has already been submitted on Domino Ideas:
DOMINO-I-2711

If you also support this direction, we kindly invite you to vote for it on the above link, so this request gains more visibility and can be prioritized in future product enhancements.

Thank you again for your valuable input!