Warning

Be aware that all information sent from the Tableau Extension, to the n8n workflow, can be manipulated by the user. They are privy, by design, to full control over the communications between the two components.

One failsafe way of preventing this is to authenticate users through network infrastructure (e.g. a proxy), which is typically an enterprise-supported option. Contact us in case this type of solution needs to be set up.

In general, without network-level authentication, a Viewer with malicious intent could theoretically find ways of spoofing the username value being sent to n8n. It is important to keep this in mind while building n8n workflows, following safe design principles, and applying mitigation actions where needed.

Regardless of internal/legitimate users' actions, the communication going into n8n should always be secured with Autom8’s Authentication mechanism. This should always be the case to also fend off external attacks. It provides a layer of protection against internal attacks too, because it requires a malicious actor to sniff outgoing traffic and spoof this authentication to start with.

Use permissions to control who can access a Tableau workbook or view in the first place. Use dynamic zone visibility to conditionally show or hide the Autom8 Extension depending on a user's role, permissions, username, etc. A bit like "row-level security", but more visual.

Use security checks in the workflow to review whether the user is sanctioned to perform the action(s). This is a first line of defense against accidentally incorrectly issued requests.

Example: check who sent the request for a certain action, and validate this against an allowlist of users sanctioned to perform that action. Note that a malicious (internal) actor can still spoof a username being sent from the Extension to the workflow, if they are invested in doing so and technically capable. Hence, also consider …

Design the workflow so data exfiltration is unlikely or impossible. If data will be modified or output by the workflow, make sure this action is tied to the incoming username. This way, if a malicious actor presents themselves as “someone else”, it’s still “someone else” who is going to receive the resulting output.

Example: imagine an Autom8 action that sends a confidential report in PDF to the authenticated user clicking the button. In this scenario, user M (Malicious) has access to data for one client. User L (Legitimate) has access to data for all clients.

• User M accesses the dashboard.

• User M triggers the Autom8 action to generate the PDF. The request contains their username, M.

• Before the request leaves their computer, they change the value of the username from M to L.

• The n8n workflow receives the request, seemingly from user L. Now here is what can happen …

• … without proper workflow design, the spoofed username could result in data being output to unexpected recipients.

• … with proper workflow design, and the right checks, L might receive an unexpected PDF export of the dashboard, but containing only data they are already entitled to. M receives nothing.