1. Network Communication & Exposure
Q: Does the user’s browser call the Self-Hosted API directly, or must it be exposed externally for Power BI Online to reach it?
A: The writeback request is made directly from the user’s browser to the Self-Hosted API.
This ensures that users working inside an internal network can interact with an on-premises database through the API without needing to expose the endpoint publicly.
Power BI Online does not need to reach the API directly.
2. Runtime, Security Monitoring & Updates
Q: What runtime is the API built on, and how are security vulnerabilities monitored and patched?
A: The Self-Hosted API is built on Node.js.
Updates are applied through a manual overwrite of the executable.
Customers should follow standard Node.js security practices—monitoring dependencies, environment configuration, and OS patching as part of their internal security processes.
3. Certificate Management
Q: Can the API use certificates from the Windows Certificate Store, or is a PFX file required? Can Azure Key Vault be used?
A: The current implementation relies on a file path reference specified in the XML configuration, such as a PFX certificate.
If the certificate is accessible via a file share, this will also work.
We are actively exploring additional methods for managing certificates more securely and natively, including cloud-based and system-level options.
4. Authentication & Access Control
Q: How is the API protected once running? Does it support API keys or user-based authentication? Can any HTTP client that knows the URL submit data?
A: The API includes a simple internal handshake mechanism, but otherwise does not restrict incoming requests.
There is no API key, and the API does not perform user-based SQL permission mapping.
Security is primarily achieved by hosting the API inside the customer’s internal network, ensuring it is not publicly exposed.
Only trusted clients within that network should be able to reach the endpoint.