The word LOCAL in MySQL's LOAD DATA LOCAL INFILE describes where the file lives. The server processes the SQL statement, but the client library opens the named file on the client host and sends its contents. This inversion is easy to miss when reviewing database permissions. The server does not need file-system access to the client path, and the FILE privilege is not the primary control.

That behavior creates a security boundary around the client application. A malicious or compromised MySQL server can ask a connecting client to read a local path when local data loading is enabled and the client accepts the request. The server initiates the transfer. A developer who thinks only in terms of server-side LOAD DATA INFILE may enable local loading for convenience without recognizing that the client is being asked to disclose local files.

Configuration happens on both sides

MySQL documents local_infile controls on the server and client-library options such as MYSQL_OPT_LOCAL_INFILE. The server can refuse local statements; the client can also decline or restrict the operation. The MySQL client supports --load-data-local-dir to limit the permitted directory when local loading is disabled by the client library, but its behavior depends on whether LOCAL loading has been enabled. A single setting in one layer is not a complete policy.

Applications that use ORMs or custom connectors may expose these options under different names. Review connector documentation and test the actual negotiated behavior. Do not infer the client setting from a server variable, and do not assume a pooled connection inherited the intended configuration.

Choose a deliberate import path

For most application imports, the client should not permit arbitrary local file reads. Disable local infile in the connector and on the server. If a trusted batch job needs the feature, run it under a dedicated identity, restrict the allowed directory where supported, and pass a fixed path rather than a value from an API request. Keep the connection separate from general-purpose application pools.

Do not expose an import endpoint that accepts an arbitrary local path. Upload the file through application code, validate size and type, store it in a controlled location, and read it with the application account's permissions. This keeps file authorization in one place and avoids turning the database server into an oracle that chooses which client file to open.

Test the policy with a low-value canary file. Confirm that a normal application connection cannot read it through a local load, even when a server-side statement is attempted. Test both the disable path and any approved batch path so a configuration change does not silently widen all consumers.

Monitor for unexpected use

Log connection identities and import operations at the application layer. At the database layer, alert on local-load activity from accounts that should not use it and on changes to local_infile. Preserve enough context to distinguish an approved batch host from a web worker or developer workstation.

The subtle risk is the direction of trust. A database connection normally lets the client trust the server with queries and data. Local file loading adds a request from the server to the client. Treat that request as a sensitive capability with an explicit owner.

References