Security Policy

1. Self-hosted architecture

ApexReporter Studio runs as a single process on a server you control — your own Windows or Linux machine, on your own network. It connects directly to your Oracle (or Postgres/MySQL) database using the credentials you configure; there's no intermediary cloud service, no data relay, and no telemetry/phone-home built into the runtime. Your report definitions, query results, and uploaded files are stored locally on that server's disk, in a SQLite database and local filesystem you control and can back up yourself.

2. Encryption at rest

Saved database connection passwords are encrypted at rest (AES-256) before being written to disk, using an encryption key that's either supplied by you in configuration or auto-generated once per installation. Admin and user account passwords are stored hashed, never in plaintext. Uploaded assets and report data are protected by your operating system's own filesystem permissions, the same as any other application data on that server.

3. License-key cryptography

Activation keys are generated by a separate, standalone key-issuing tool, signed and authenticated (encrypt-then-MAC, so a tampered or forged key is rejected rather than silently misread) so a key can't be fabricated or altered client-side to unlock a plan you haven't purchased. A key can optionally be locked to one machine's hardware fingerprint, shown on the application's own activation screen, if you want a key that can't be copied to a second server.

4. Authentication & access control

Access to the designer is session-based, with role-based permissions (Administrator/Designer/Viewer and finer per-user overrides) controlling what each signed-in user can see and do — including report/connection sharing, personal vs. team folders, and an audit log of administrative actions. An optional API key can be issued for trusted external callers (e.g., an Oracle APEX integration) that need to invoke report rendering without an interactive login.

5. Network exposure

By default the application binds to a port on your server and is not exposed to the internet unless you choose to put it there. We recommend running it behind your own reverse proxy (e.g., nginx) with HTTPS/TLS termination, restricting allowed origins (CORS) once real users are involved, and keeping it off the open internet entirely unless you specifically intend external access — the same guidance as for any self-hosted application. See the deployment security guidance in the documentation.

6. Your responsibilities

Because the product is self-hosted, the security of your specific deployment depends on choices only you control: keeping the host OS patched, restricting network/firewall access appropriately, using a strong admin password, rotating the encryption/API keys if you suspect compromise, and applying application updates when we release them. We can advise, but we can't enforce any of this remotely — there's no central service watching your install.

7. Updates & patching

We ship patches as updated runtime packages; applying one is a code-only replacement that never touches your data (see the Installation & Patch Update guide). We recommend staying reasonably current, particularly for any release that specifically mentions a security fix.

8. Reporting a vulnerability

If you believe you've found a security issue in ApexReporter Studio, please report it privately to sales@apex-reporter.com with enough detail to reproduce it, rather than filing it publicly. We'll acknowledge your report, investigate, and let you know once a fix is available before any public disclosure. We don't currently run a paid bug-bounty program, but we're genuinely grateful for responsible reports and will credit you if you'd like.