HTMLdb Developer

Security

A workbench that can change your database has to be careful about who uses it. These are the layers every HTMLdb app goes through.

1

Signed in with App Builder

The page only opens for someone signed in to APEX App Builder, in the same browser, as a developer of the workspace. Every request after that is checked again: a live APEX session of the application, and the developer login behind it. Nothing in a request runs before that check passes.

2

Nothing trusted from the browser

Each app answers only POST requests to its own package. Who the user is and which workspace they are in come from the checked session, never from what the browser sends. Schema and object names go through DBMS_ASSERT, values are bound, and branch names, file paths and issue keys are checked before they reach a GitHub or Jira address.

3

Secrets stay on the server, encrypted

The Credential manager stores API keys, OAuth tokens, token requests and certificate chains with AES-256 (CBC, PKCS5) and a new random IV for every value. Each value records the key that encrypted it, so the master key can be replaced. The browser never receives a secret; it only learns whether one is set and its last four characters. Each API is called with only its own trusted certificate chain.

4

Every change reviewed

Code moves from DEV to TST to PRD by pull request. Before a merge, an AI security review reads the whole code, in parts when it is large, and posts its findings on the pull request. Work that is not ready goes back to DEV with the reasons, and shows on the object until it is promoted again.

5

On the record

Git keeps the history of every object. The Credential manager logs every create, change, delete, token refresh and certificate refresh, without the values. Each database has its own colour on every screen, so PRD never looks like DEV.

Encryption in the database protects data exports, backups of the tables, screenshots and anyone reading the tables directly. Protection against a database administrator needs the key held outside the schema, such as Oracle Transparent Data Encryption or a separate key owner.