**Domino/Notes Version：Domino R14.5
**Client：Notes,Nomad Mobile
Problem/Query:
Across all current Domino versions, any user with a valid Notes ID can connect to Domino databases through external programs (Java, COM, Python) using standard APIs. Once authenticated, these sessions are treated the same as Notes client sessions, with no native mechanism to restrict or differentiate programmatic access.
Observed Impact:
A user with Author-level ACL can read all documents if Reader fields are not present.
Design-level security (e.g., hiding fields, UI restrictions) can be bypassed through API calls.
Questions:
Is there a way to block or limit external API access (Java/COM/Python) while allowing standard Notes client use?
If not, is there an official method to monitor, log, or distinguish API-based sessions from Notes clients?
Are there recommended security best practices or policy settings to mitigate this risk?
Additional Note:
Once a user authenticates with a valid Notes ID, they can use external programs (e.g., Java, COM, Python) to access Domino and extract all NSF data. This bypasses UI restrictions and poses a significant security risk. Are there any measures to block, monitor, or control such access?
I am not on the product team, so I have no answer regarding a way to block or limit external API access or monitoring api session content.
HOWEVER, I do want to point out that the issue you describe is Notes / Domino security working as designed.
A user with Author-level ACL can read all documents if Reader fields are not present. - Yes, exactly. Use ACL settings and Reader fields to control access to content.
Design-level security (e.g., hiding fields, UI restrictions) can be bypassed through API calls. - CRITICALLY IMPORTANT POINT - Hiding fields and UI restrictions is obfuscation only, it is absolutely NOT security. The proper way to control access to document and field-level content is to make use of Database ACL, Document Reader Fields, and (if needed) field-level encryption.
Thank you for your response and clarification. We would like to provide some additional details as follows:
1. Follow-up Regarding API Access and Security Risks
We fully understand your point that design-level security (such as hiding fields or UI restrictions) is only an interface-level limitation and not a true security measure, and thus can be bypassed through API calls.
However, this is exactly the main risk we are currently facing:
As long as a user possesses a valid Notes ID and successfully authenticates, they can directly access the database through APIs or external programs without launching the Notes Client.
While ACL and Reader fields can provide granular access control, we are unable to use Reader fields due to the large number of application users and their high frequency of changes, which would severely impact server performance and cause significant delays.
Therefore, in the absence of Reader fields, once authenticated, a user could potentially access and extract all documents and field data in the database, which poses a substantial security risk for us.
2. Additional Clarification
Currently, any user with a valid Notes ID and authentication can connect to the Domino server and extract all database data via external programs (such as Java, VB, Python, etc.) without opening the Notes Client. This effectively renders the front-end UI-based security controls (such as hidden fields or UI restrictions) ineffective, increasing the risk of data leakage.
Given this situation, we would like to ask:
Is there any existing mechanism to prevent or restrict authenticated Notes users from accessing data through external programs?
If not, would it be possible to provide features to monitor or detect abnormal API or external program access to reduce such security risks?
Thank you again for your assistance and advice. We look forward to your response.
Did you actually try to extend your application(s) to make proper use of reader fields and then measure the impact on server performance? Or do you just assume that this would cause significant delays?
In any case you need of course to provide appropriate hardware resources that match the requirements of your use case.
Btw: Did you evaluate HCL Nomad Web as a potential alternative for the Notes client? With Nomad Web your Notes apps run in a browser sandbox environment that external programs are not able to call into.
Thank you for your suggestions. To clarify our situation:
Reader fields: We previously tested this approach. Due to the large number of users and frequent data updates, the result was severe server delays—users could not open documents via document links for processing. Therefore, applying Reader fields at this scale introduces significant operational and maintenance challenges.
Nomad Web: While Nomad Web allows users to access Notes applications through a browser without installing the Notes client, it does not address the root issue.
Technical note: Nomad Web runs in a browser sandbox using WebAssembly and SafeLinx/HTTP, which indeed prevents local external programs from calling into Nomad itself. However, this does not block external programs from connecting directly to the Domino server via Notes API or COM from any environment where the Notes client or API libraries are available.
In other words, Nomad Web changes the client delivery method but does not restrict API-level access for authenticated users.
Our main question remains: Is there any official solution or best practice to restrict or monitor authenticated users from accessing Domino data through external programs after passing Notes ID authentication?
Using API access doesn’t grant you any more access than a Notes client user can.
I would look again at introducing readers fields. If users experienced delays opening a document link then I would guess it’s an embedded view, or view lookups causing the problem. You need to look at redesigning views so that lookups and view openings are not skipping lots of hidden documents thus causing significant delays.
Thank you for your feedback and suggestion. We fully understand that API access does not grant additional rights beyond what a Notes client user already has.
Regarding your recommendation on Reader fields, we have tested this approach in the past. However, due to the very large user base and frequent document updates, implementing Reader fields created significant operational and performance issues:
Each time access control changes, Reader fields on many documents need to be updated, triggering heavy index rebuilds and view refresh operations.
With thousands of users and frequent changes, this approach led to severe delays in real-time operations. For example, users often experienced timeouts or inability to open document links during processing, even after optimizing view designs.
The root challenge is that Reader field-based control does not scale well in high-volume, high-frequency environments, even with careful view optimization.
Our primary concern remains that once a user is authenticated with a Notes ID, external programs can still access and extract all data from the NSF database, regardless of any UI-level restrictions. We are seeking any official guidance or best practice to restrict or monitor such API-level access without relying solely on Reader fields.
Thank you for your insights, and we look forward to your advice.
For legitimate code access make sure the code is properly signed and configure the ECL accordingly.
Also make sure you leave the “Don’t prompt for a password from other Notes-based programs” setting unchecked. Then any external code, that tries to access a Notes database, will result in another password prompt, even if the user session in the Notes client is already authenticated.
If for whatever reason you assume that malicious code, that is trying to use the Notes binaries, can be executed on a users workstation, you must also educate your users and tell them not to authenticate such code.
The problem you describe is called “unauthorised behavior of the authorized user” and the proven remedy is restricting access to what data is reachable. In case of Domino that is achieved, as pointed out in this thread, using reader fields.
So the question opens: how to make reader fields work for you. To answer that, we need to know a little more about your application. How many users and documents are we dealing with and what update frequency.
Furthermore: hardware layout, ODS and if you keep the indexes outside the NSF? Are we dealing with large documents (Attachments)?
THAT requires explanation. What external factors change Access Control? What we typically see in protected applications is computation of Readers on document save (both new and updated) and users moving in and out of roles or groups. Neither triggers massive updates. So there might be improvement potential. Also view design matters.
Reader fields do have a performance impact, that’s understood, but I’m sure it can be tamed into an acceptable one.
The API access isn’t accessing the Domino API, Domino “only” gets NRPC connections, the accessed APIs are on the Notes client. So you are looking at a workstation lockdown (Bigfix could help). However, keep in mind, you are dealing with an authorised user (misbehaving), a local agent or a code in a button in the toolbar can run LotusScript extraction code.
So Reader fields it is.
Unless: You consider using Domino’s HTTP capabilities (Nomad, XPages or DRAPI), instead of the client so a user never can access the NSF directly and only interacts with HTML in the browser.
Let us know what we can clarify further and share more about your app
Hello notessensei, HCLSoftware, thank you for your feedback and suggestions. Please allow us to provide additional details:
1. Why Reader Fields Are Not Feasible in Our Environment
We have been using Domino and Notes for many years, with tens of thousands of users, over 1,000 applications, and tight integration with ERP systems. Data changes are extremely frequent.
We previously tested Reader fields for access control, but the results showed severe performance degradation when Reader field values changed frequently.
This caused users to experience significant delays when opening document links, sometimes making the documents completely inaccessible, and overall server performance dropped drastically.
The root cause: Reader field changes triggered massive index rebuilds and view refresh operations, which are highly disruptive in a high-volume environment.
Additional environment details:
Hardware: Cluster configuration
ODS: Currently R11.0.1 (upgrade to R14.5 planned by year-end)
Indexing: Indexes are not stored outside NSF
Documents: Most documents include attachments
2. Our Core Concern
Our applications run entirely in the Notes Client environment, but any authenticated user with a valid Notes ID—even without opening Notes Client—can leverage VB, Java, or other programming languages to build scripts that bypass all UI-based security controls and extract the entire database content in bulk.
This means all front-end security measures are ineffective against such actions, creating a serious security risk.
Our Request
Are there any official recommendations or alternative mechanisms to restrict or monitor such external program access beyond relying solely on Reader fields?
repeating the question will not change the answer. The question was understood the first time. Let’s put some context:
UI-based security controls
There is no such thing. UIs guide, but do not secure, so treating UI (on any platform including web) is NOT security.
Data access: you don’t need external code to access a Notes database. A button added to the toolbar or inside a local custom nsf will do the trick.
Or: a private view and copy & paste to Excel
So the answer stays: access control is performed using ACL and reader fields.
What you could do (I would strongly discourage you due the complexity and cost): Use something like Citrix to put the Notes client into a „caged“ environment and use network controls to disallow other Notes clients.
Or switch to Nomad which you can also network control. Which still leaves you with the code in a button.
So the question that helps you progress is (again): How to make reader fields work for you. A few additional pointers:
R11 is 6 years old. Any resolution will need the current version and the current ODS
External view indexes on fast hardware make a difference
How you construct a doclink makes a difference. Are you sending the view /unid/ or are you use /0/
Are your servers and admins included in an author field
Can changes to the reader fields be lessened by use of groups and roles (specific to your business requirements)
view design is important (see previous reply)
May I suggest to engage HCL professional services for upgrade and app modernisation.
Thank you for your response. We understand that HCL recommends using ACL and Reader fields as the main access control mechanism. However, in our environment, there are practical challenges that make this approach problematic:
Our user base is in the five-digit range, with over a thousand applications running on Notes Client, and data changes are very frequent. Using Reader fields would result in frequent updates, causing index rebuilds and view refreshes that can negatively impact performance.
Our document links are primarily generated via LotusScript / @MailSend. We would like to clarify the difference in performance and security implications between using /unid/ vs /0/ in such cases.
Due to the complexity of document workflows, Reader fields inevitably change multiple times during the lifecycle of a document (e.g., three levels of approval). We are concerned whether this will slow down document access and processing.
Our infrastructure currently uses R11 (server and clients), with plans to upgrade to R14.5. ODS is still on R11. We use cluster configurations, indexes are stored inside NSF, and documents often contain attachments.
We have already implemented security measures: disabling URL access to NSF databases, restricting data export, and hiding design elements where needed. These measures reduce some risks, but they cannot prevent technically skilled users (e.g., VB/Java developers) from using external programs to access data directly if they have a valid Notes ID.
Our core concern is:
Once authenticated with a Notes ID, a user can access and extract the entire database using external programs (Java, VB, Python, etc.), bypassing the front-end UI restrictions. This represents a significant security gap for us.
Therefore, we would like to ask HCL:
Is there any server- or ACL-level setting to restrict or block API/COM access, ensuring that only Notes Client can connect?
Are there best practices for making Reader fields effective in high-volume, high-frequency environments like ours, without impacting performance?
The over the network API (stuff running somewhere else than the Domino server is only NRPC. Additional protocols (HTTP(s), POP3, IMAP4, SMTP, Corba) need to be explicitly enabled. So there is no Domino access with Java, VP, Python etc. to Domino over the network.
What you refer to is API access to a locally installed Notes client. The Domino server only sees NRPC requests coming in from a properly authenticated Notes client. So any defence would include controlling the OS the client runs on and preventing unknown code to execute. This is outside the scope of the Notes client’s capabilities.
without impacting performance
ANY security measure has a performance impact on EVERY platform. So I take your question as “limit the performance impact”.
A few pointers:
Optimize your hardware layout. Different I/O channels make a huge difference
Use DAOS for attachments
Keep the view indexes outside the NSF
Ensure servers have access to all documents (I use a AUTHOR field for that)
Minimize changes to Reader fields (more below)
View design group documents that are readable together
A workflow process with 3 levels of approvals. On initial creation name fields are created (in yellow). Out of the name fields ONE reader field gets computed which in this case only changes once a process is complete. An author field takes care of edit to access. This approach distinguishes between “must not see” (all documents) and “does not want to see” (e.g. Approver after approval).
There are unlimited variations to that pattern regarding fields and formulas. One variation I quite like is to have a computed AUTHOR field called “ServerAccess” with the formula “[serveraccess]”. The role will get added to all servers and admins in investigative situations. Why AUTHOR? Servers usually have manager access, where author fields don’t seem to matter? Except an author field includes READ access without triggering read protection. A reader field triggers protection you might not want.
Once you share more on the application logic we can advise on the right course of action.
We acknowledge that Domino itself only sees NRPC requests from authenticated Notes clients, and what we described earlier as “VB/Java connecting to Domino” should not be confused with an “external API.”
Our actual concern is that VB, Java, or similar programs can use locally installed Notes client components (COM or Notes.jar) to connect to the Domino server via NRPC in the same way as the Notes client UI.
This makes it very difficult for administrators or developers to distinguish whether a given NRPC connection is coming from an interactive Notes client or from custom code running locally.
Our key requirement is therefore:
We would like Domino to provide a mechanism to differentiate between NRPC sessions initiated by the Notes client UI versus those initiated via local programmatic access (VB, Java, etc.), so that administrators can monitor and control these scenarios separately.
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();
}
}
}
These examples demonstrate that a properly authenticated Notes ID can establish a full NRPC session without using the Notes client UI.
This is the behavior we are most concerned about and would like to manage more effectively.
Thank you very much for your previous explanation and for sharing the sample design of the three-tier approval workflow, which is very helpful for our evaluation.
In addition to our earlier clarification regarding the use of VB and Java connections to the Domino server (which should be described as API-level access rather than “Notes API”), we would also like to provide you with our current application design and raise several further questions for your guidance:
Application design
Our workflow application also uses one Author field, one Reader field, and multiple Name fields to record different processors in each stage. Currently, we do not apply reader-field restrictions, so the Reader field is either left empty or set to "*".
If we adopt Reader field restrictions in the future, this would require us to dynamically write the corresponding Notes IDs of different approvers into the Reader field during each approval stage so that they can access the document. Would this cause the Reader field to be updated very frequently?
View index placement
Our applications (.NSF) are currently running on SSD storage under a clustered environment. Do you recommend separating the view index from the .NSF file in this case?
Attachments storage
At present, all document attachments are stored directly in the attachment item of the documents. Would you recommend using DAOS for such cases? What would be the performance or efficiency difference between using DAOS versus not using it?
Next step
We may attempt to introduce Reader-field restrictions in a trial environment to observe its impact. Your guidance on the above points would be greatly appreciated.
Ad 1:
You need to look at your business process. Usually in an approval flow all participants are allowed to see the documents they are involved with, end-2-end, so your Reader field wouldn’t change much. What you want to control is the Author field which determines who can update the document. Note that this required the ACL for participants to be Author. Also good practise: Have an (additional) computed Author field with “LocalDomainServers” to ensure server access (Author field, not Reader! since it maintains access without locking down the document) even if the server(s) have manager access
Ad 2:
You need to measure. It all boils down to throughput of you I/O subsystem. One observation on Domino: memory usage spikes when available I/O bandwidth is insufficient. My guess: separation I/O will have benefits. As has ODS55 on Domino 14.5
Ad 3:
Yes, absolutely. Easier backup, smaller NSF, less fragmentation, different I/O channel. Again depends on your concrete setup.
Thank you for your suggestions and for pointing us to the Domino Ideas portal. We understand that OS-level measures such as restricting managed clients, disabling COM, or limiting local admin rights are important controls.
In our environment, we already prevent URL access to databases, restrict export in sensitive workflows, and apply design hiding where appropriate. Our main concern is at the Domino server level — specifically, we would like a way to distinguish Notes Client connections from those initiated via VB/Java programs over NRPC.
Therefore, we believe an enhancement request to add ACL or server-level options for controlling this type of access would be very valuable, and we will proceed with raising it on the Domino Ideas site.
Our key requirement is therefore: