I Found OAuth Credentials in the Clear Inside the new DocuSign SuiteApp - DocuSign Confirmed It

Last updated: 2026-07-27

I spent a couple of hours poking at the new DocuSign SuiteApp on NetSuite and found OAuth credentials sitting in the clear on DocuSign's custom records, plus production source code that any internal user with file cabinet access could edit. I reported it and DocuSign confirmed it is a real product security issue their engineering team is now fixing. Here is what I saw, and what you do about it while the patch is in flight.

As I reported earlier, NetSuite is now forcing adoption of the newer SuiteScript 2.1 and SDF deployment standards on its customers. It is the same push every SDN publisher is getting right now, the move off the old SuiteBundle model and onto the SuiteApp Manager and SDF. So I did what I always do when a vendor ships something new into an account I own. I opened it up and inspected it from a security perspective to ensure access is properly limited by role.

Within a couple of hours I was staring at OAuth credentials for the DocuSign integration sitting in plaintext, inside a NetSuite custom record that was only hidden from UI access. So, there was my OAuth token sitting there, not encrypted to my surprise. Not masked. Just sitting there for any internal role to read with access to SuiteScript.

Let me be clear about one thing before I go any further. This is not a takedown of DocuSign. They are a serious vendor and I still use and recommend the product. But, this is the kind of thing that happens when a migration to a brand new packaging technology moves fast and the security design step gets compressed. If I am being honest about my read, it almost feels like someone took the old SuiteBundle, ran it through the 2.1 migration to get it out the door, and never did a real security review. I do not know that for a fact, and I am not asserting intent. I am simply telling you what the default state looks like in a live account.

About ten years ago when we were selling NetSuite, we would spend a good fifteen minutes on the pitch just on security. How the roles work, how permissions gate the data. Now it is a one slider and everyone wants to skip ahead to pricing. The platform did not get less careful. We did, and a rushed publisher migration is exactly what that looks like in the wild.

What I actually found

Two custom records back the integration. They are called Docusign SuiteApp Instanced App and Docusign SuiteApp OAuth, and both install with an Access Type of "No Permissions Required for Internal Roles." In plain terms, if a user has any internal role in your account, they can read those records. There is no permission gate in front of them.

Here is the part that got me. Allow UI Access is unchecked, so an admin glancing at the record would reasonably assume the data is hidden. It is not. That flag only governs the native UI. SuiteScript and the record APIs read it just fine. It is a control that looks like a lock and is not one.

Now look at what those open records hold. The secrets are stored as Free-Form Text and Long Text. The Client Secret, the Client Secret Key, the full OAuth JSON payload, all of it in readable fields. NetSuite hands you a Password field type for exactly this reason, so an integration never has to store a secret in plain text. It was not used here.

Then there is the source code. The suitelets that run the integration show an Edit link in the script list, not the padlock icon you see next to a properly locked managed object. And editable is literal, you open one and you are dropped straight into the source with a live Save button. The File Cabinet lists the ten files behind those five suitelets, the compiled .js and the source maps, with Edit and Download right there. Holy moly! From an IP and IT controls perspective, editable production integration code is a real no-no.

Put those two things next to each other and you have a textbook segregation of duties problem. A single internal actor can read the OAuth credential and then edit the very code that handles it, with no managed-object protection standing in the way. For anyone operating under SOX or SOC 2, that is not a theoretical risk. It is a finding.

And it gets worse the higher up you go. Because those records are wide open, every user with the Administrator role can read the OAuth credentials of every other user in the system. There is no per-user boundary at all, which really makes it hard to accept this bundle without the security patch for many organizations I would imagine.

Always encrypt user credentials

I do not want you to walk away thinking the platform is the problem, because it is not. NetSuite gave the publisher everything needed to do this safely, but for whatever reason they did not use the N/crypto module. Role based access you can scope down to a subsidiary or a department. A Password field type was built for exactly this use case, so a secret never sits in the clear, the same goes for the N/crypto module. The other issue is not properly locking managed objects that keep production code from being edited at all. Every one of those guardrails is offered by the platform and for whatever reason they were skipped and they put a lot of NetSuite customers in jeopardy if they are not as careful as I was.

The bigger pattern

This is the part I keep coming back to. NetSuite is strongly advocating for everyone to migrate to SuiteScript 2.1 and SDF, which has significant improvements in both runtime and security including the cryptography library and strict mode, which is all gravy and the right direction for the platform. But a forced migration is precisely the moment when hardening and QA can get squeezed. And I think 2026 is going to be one full of stories like this one, where a fast move to new packaging, or heavy reliance on AI-generated code for the majority of the mechanical migration, ships something that runs but was not properly designed and/or tested for security. The majority of software development (80 percent) I'd argue can be generated very easily. But, that hard part is really the 20 percent that is actually making sure it is safe to deploy for everyone else is the part that keeps getting skipped, and that's where human judgment really comes into play.

What to do this week

If you run the DocuSign SuiteApp on NetSuite, treat the following as an audit and remediate pass. Do it in a sandbox first, then production.

Before anything else, look at your Administrator roster. Because those records are open, every admin can read every user's DocuSign credentials, so that role belongs to your security people and your business owners and nobody else right now. It may be necessary to even uninstall the SuiteApp if you cannot properly ensure the access to credentials and script files are properly locked down from regular user view and edit access respectively.

DocuSign SuiteApp Installation Security Checklist:

1. Lock down the record access. Change both custom records off "No Permissions Required" and onto a permission list, then grant only the roles that actually operate DocuSign.
2. Rotate the DocuSign credentials. Assume the cleartext secrets were already readable. Rotate the OAuth client secret in DocuSign and re-authorize, so any previously exposed value is dead.
3. Audit who could have read them. Review every role with SuiteScript or saved-search access to those record types, and pull the access log where you have it.
4. Confirm the source is locked. Verify your suitelet objects show the managed-object lock rather than an Edit link. If they are still editable, restrict File Cabinet and script-edit permissions until the publisher ships locked objects.
5. Scope envelope visibility. Test with a non-admin role that signers only see their own envelopes and not the whole account's, and fix the record and search restrictions if they do not.
6. Open a case with DocuSign. Ask for their security configuration guidance and whether locked objects and a Password field type are on the roadmap. Get the answer in writing.

Where I land

A managed SuiteApp from a name-brand vendor is not the same thing as a secured one. Installed and hardened are two different milestones, and the gap between them is where the risk lives. A serious integration like this one really does need a NetSuite Solution Architect to analyze it, configure it, and test that everything works safely. That is not a knock on the product, but it is a knock on this version of the SuiteApp and how it was published. It is just the reality of running a real integration inside a financial system, the publishers need to provide some sort of Administration Handbook or Online Guide to its users. The fact that this has been a known security issue and still hasn't been corrected is very concerning to me.

If you run DocuSign on NetSuite, and you have any concerns about security, feel free to book a consultation.