Thousands of NetSuite stores leak sensitive data due to access control misconfiguration

How does this lead to misconfigurations?

Let’s assume an administrator creates a CRT with “No Permissions Required.” In adding custom fields, he wants some fields to be readable by unauthenticated users, so he sets their Default Access Level to View; other fields that should not be readable, he sets Default Access Level to None, assuming the job is done.

This would be incorrect because the “Default Level for Search / Reporting” (DLSR) setting is still Edit, even if Default Access Level is set to None. And this, Costello shows, can be abused through the NetSuite API to read the data in that field. The confusion here could be caused by the fact that fields with Default Access Level set to None cannot have their data read through the SuiteScript API loadRecord function, which is part of the N/record module and contains the most popular functions for performing CRUD (create, read, update, delete) operations on individual records.

But there is a different API function called nlapiSearchRecord, part of the N/search module, that can also be used to read data from record fields, and the permission for this API is defined by the DLSR setting. The difference is that reading field values with nlapiSearchRecord requires knowing the field name, while reading data via loadRecord requires knowing the field ID. Luckily, the data obtainable from the two APIs complete each other.