Files.com welcomes independent penetration testing. We publish this Security Reference so your team can understand the product, plan meaningful tests, and evaluate the results against behavior we commit to supporting.

Our testing program combines automated scanning, independent penetration tests, and ongoing product security testing. It covers common web application issues as well as the product-specific boundaries below. An assessment limited to port scans, scanner output, and standard web application checks largely repeats work we already do. Our testing and scanning program describes that coverage and the independent assurance available to customers.

The most useful additional testing examines how controls work together: a restricted credential used by an administrator, an Automation processing a partner's input, a file reached through another site's storage, or a connection that remains open after access is removed. These cases require an understanding of what the product should permit. We encourage you to test all the areas below, including combinations and variations we have not listed.

Authorization and Scope

Customer assessments require advance coordination under Customer-Performed Penetration Testing. Eligibility requires an Enterprise plan, a signed testing agreement, and agreement to share the full results with Files.com. Contact your account representative or Support to establish the scope and timing before testing.

Independent testers participate through the Files.com security testing program, which has its own eligibility, scope, rate limits, reporting requirements, and stopping rules. Follow the policy for your engagement, including restrictions on individual features and installed software.

Use sites, accounts, domains, and external servers you control and are authorized to test. Testing one site does not authorize access to another customer's data or systems.

Test Design

Read the entire Security Reference before planning or performing tests. Use it to establish the expected result for each test, together with the Files.com Developer Documentation, your site's configuration, and the agreed scope.

For example, an application may hold a Files Only API key restricted to an upload folder while an Automation delivers those uploads elsewhere. The key's restriction governs the application's requests. The Automation runs with its configured owner's authority. A file arriving outside the upload folder can be the intended result; a request made with the restricted key reading that destination directly is a different test.

Prepare accounts and credentials that let you distinguish these sources of authority. Include an administrator, ordinary users with different folder permissions, and the delegated administrators relevant to the feature. Compare direct grants with Group membership, and test users who hold several grants together. Use separate sites and Workspaces when assessing those boundaries.

Test credential restrictions independently of the account's permissions. A Files Only key owned by a Site Administrator is a useful case: the owner's broad access must not erase the key's narrower scope. Test with and without a path restriction. Include app credentials, SSH keys, S3-compatible access keys, visitor sessions, and signed transfer URLs where they apply.

Files.com is API-first. For every endpoint in scope, compare the Authorization Requirement in the Developer Documentation with the result for each account and credential. Include operations and parameters that the web interface does not expose, and repeat applicable file operations through FTP, SFTP, WebDAV, and the S3-compatible endpoint. A missing button does not establish a service restriction.

For each restricted operation, first confirm that the same operation succeeds with an authorized account. Then change the account, credential, resource, or setting being tested. This makes it easier to distinguish an enforced permission from an invalid request or an unrelated failure.

Sites, Workspaces, and Connected Storage

Files.com separates unrelated customers while allowing administrators to connect their own sites and external storage deliberately. Assess both separation and the access those connections are intended to provide.

With two unrelated test sites you control, try using one site's credentials and resource identifiers against the other. Include file reads, configuration, previews, exports, Snapshots, and background work such as Automations and Syncs. A credential or identifier from one site must not supply authority on another. Customer Isolation explains the separation, including subdomain reuse and Custom Domain ownership.

Test the boundaries inside a customer's deployment too:

A Workspace Administrator's administrative authority must remain within the assigned Workspaces. Try referencing another Workspace's folders, users, permissions, keys, Remote Servers, Agents, Syncs, and Automation resources.
A Child Site Administrator must not gain authority over the Parent Site or sibling sites through that grant. Include shared directory entries and combinations with Group or Folder Admin access.
A Connected Site operation must satisfy both Guest-side access and the Host Partner's permissions. Test listings, counts, previews, copies, and automated work across chains of routes and mounts. Narrow the Host-side permission and repeat the operation through the existing connection.

Include per-site locks and Archive Only rules when a route crosses site boundaries. Administrative authority or a lock bypass on one site must not lift protections enforced by the other.

Include names and addresses in this work. With domains and subdomains you own, test whether reassignment carries any previous site's users, credentials, configuration, or working links. Check that hostname variants cannot assign one Custom Domain to two sites or obtain a managed certificate without the required domain checks.

Folder Permissions and Delegated Administration

Folder permissions are additive. A user can receive access directly and through several Groups, while credential restrictions and other controls still apply. Test the effective combination rather than treating each grant as an exclusive access level.

Useful file-access tests include:

Combining Read and Write grants, then attempting replacement, rename, move, and delete. Write includes a limited allowance for completing or resuming an upload; test whether it can be used to replace an unrelated or completed file.
Retrieving content with List or List/Preview access through previews, thumbnails, converted formats, copies, bulk downloads, and S3-compatible reads. Distinguish an allowed preview from access to the original file.
Moving, copying, renaming, and restoring folders protected by a Permission Fence or a non-recursive grant. Recheck inherited access, parent Share Links, Public Hosting, and listings afterward.
Comparing permission checks with the actual file selected on native and mounted storage. Include case, accents, Unicode forms, and names that the connected storage system interprets differently.

Delegated administration deserves the same attention. A Group Admin may have authority over ordinary accounts in a Primary Group without being allowed to control administrator accounts in that Group. Test user changes, password and email changes, two-factor authentication resets, lifecycle exceptions, and bulk updates with the optional capabilities enabled and disabled.

A Partner Admin must stay within the Partner's Root Folder, permissions, and enabled capabilities. Test changes to user layouts, permissions, administrative access, and email recipients. In particular, additional recipients for ordinary messages must not become recipients of account-recovery or sign-in credentials.

For Folder Admins, compare permission-record visibility with the folders they administer. Test whether starting a configured process also gives access to its configuration: permission to start a Sync through an Automation does not give permission to view or change the Sync itself. Also test the write restrictions of Read-only Site Administrators and the limited scope of Billing Administrators.

Authentication and Credential Scope

An account can connect through several methods, and those methods do not all use the same checks. Use the Authentication Methods reference to determine which checks apply to the credential you are presenting.

With two-factor authentication required, exercise each supported sign-in route. Test the documented reuse limits for transfer-protocol codes across source addresses, server addresses, protocols, and expiration. For Login Attempt Protection, reach the configured lockout threshold through one interface and check sign-in through the others, within your engagement's request limits.

Directory integrations add several useful tests:

For SAML, vary signatures, signing certificates, issuers, audiences, assertion timing, and repeated use of an assertion. Include a second site you control with the same identity-provider configuration.
For LDAP, test usernames containing filter characters or wildcards, empty passwords, and directory responses that do not confirm a successful bind.
For SCIM, try updating accounts managed by another provider configuration, adopting an existing Group by name, and adding users from another Workspace or users ineligible for Group membership.

API key scope is a separate test from sign-in. Use a Files Only key against management operations and configuration reads, including when its owner is a Site Administrator. For a path-restricted key, test both ends of copies and moves. For S3-compatible access, test multipart operations using a different key, path, or upload identifier.

Creating a Full Access key with a path must be refused. For integrations that need Full Access, test the account's permissions and Workspace scope, and evaluate the execution permissions of workflows the key can configure.

For Desktop, Mobile, and Online Editor credentials, test the credential's permitted operations, issuance, expiration, and renewal. App sign-in tests should include callback destinations, repeated use of pairing credentials or authorization codes, and the proof required to exchange a code. An app credential must not acquire the management scope of a Full Access key.

Account recovery and sensitive changes need tests of their own. Check recovery links against the intended account, primary email, account type, and enrolled two-factor methods. Exercise re-authentication through alternate update routes and consecutive writes, while preserving the documented distinction between login sessions and API keys. Include Shared/Bot accounts, which have separate restrictions on self-service account changes.

Access Removal and Expiration

Test access removal with credentials and sessions established before the change. A failed new sign-in alone does not establish what happened to an existing app connection, visitor session, refresh grant, or transfer URL.

Begin with a successful operation, make the change, and repeat the operation using the existing connection. Compare the result with Access Revocation. Important cases include:

Changing a password, deleting an individual key, disabling a user, and letting the user's access expiration pass. These actions have different effects; a password change does not revoke separately issued API or SSH keys, and disabling a user does not revoke site-wide keys they created.
Turning off a protocol or app while connections are active. On FTP and SFTP, use an operation that requests new information or performs new work. A repeated cached listing does not establish continued access.
Revoking a Share Link, changing its password, reducing its allowed actions, or lowering the site's link-expiration limit. Recheck existing visitor sessions as well as new visits.
Narrowing a paired Remote Server key or disabling remote access on the other site. Recheck existing mounts and Share Links that use the connection.
Ending a Remote MCP session or disabling AI features. Test renewal as well as the current session, and include API-key connections when testing the AI setting.

Also test restoration. Restoring a deleted user can recover eligible credentials and permissions removed with the account. Compare results with and without Restore User Permissions, including credentials removed shortly before deletion and Group memberships that should remain absent.

Keep independently authorized work distinct from continuing account access. Signed transfer URLs have their own lifetimes, accepted background operations can finish, and copies already made can have their own access rules. Test those documented limits without assuming that every account change recalls previously authorized work or downloaded files.

Immutable Content

Finalized Snapshots and Archive Only Mode restrict changes even by administrators. The useful tests combine those restrictions with operations already in progress and alternate ways of reaching the files.

Finalize a Snapshot while copies, moves, renames, and deletions are queued or running. Check whether any file present at finalization was replaced, changed, moved, or removed. An accepted transfer adding a file after finalization is different from changing a file that was already protected.

On an Archive Only site, attempt changes through each protocol, mounted storage, Parent Site access, and Connected Site routes. Include administrator accounts. Test the limited allowance for the uploading user to finish setting file attributes, using another user, an expired allowance, and an upload without an associated user.

Check expired Snapshots separately. On an Archive Only site, retained files remain available to Site Administrators while access for other users and Share Link visitors ends.

Outbound Connections and Server Identity

Many Files.com features intentionally contact customer-selected destinations. Receiving a request at a server you configured establishes that the feature works. A useful security test checks where the request may go, which identity checks precede authentication, and which credentials accompany a redirect.

For webhooks and event delivery, test private, loopback, link-local, unresolvable, and disallowed-port destinations. Include IPv4 and IPv6 forms, mixed DNS answers, backup URLs, and changes between configuration and delivery. Check each delivery path; validation when saving a setting does not by itself establish validation when sending.

For HTTP file imports and HTTPS WebDAV, redirect between servers you control and inspect the receiving requests. Change the scheme, hostname, and port. Configured import headers and stored WebDAV authorization must not follow a redirect to another origin, and an HTTPS WebDAV connection must refuse a redirect to plain HTTP.

Test required certificate and host-key checks by presenting an incorrect identity from your server. Check whether Files.com stops before sending credentials. Include SFTP with a supplied host-key pin, FTPS, HTTPS WebDAV, secure LDAP, and Custom SMTP with encryption required. For SMTP, distinguish a failed TLS handshake from a server that never offers STARTTLS under an optional encryption setting. For remote FTP, test nonpublic or malformed passive-mode addresses against the documented address handling.

For AS2, distinguish transport identity from message and receipt signatures. With incoming signature validation set to Normal, change the signed content, certificate, and partnership identifiers. Compare failure receipts for decryption, parsing, and signature failures; they must not reveal whether unverified encrypted content was decrypted.

Automations, TransformScript, and AI

An Automation may process data from someone who has much less access than its owner. Test whether that data can direct work beyond the documented rules, while accounting for the authority the administrator deliberately gave the workflow.

For Automations v2, supply filenames, file contents, metadata, webhook bodies, and email subjects that affect paths or other settings. Include separators, parent-folder components, encodings, Unicode variants, null bytes, and values of the wrong type. Test the final destination after all templates and replacements have run.

Double-brace values in path fields represent one name. Triple braces and Destination Path Replacement deliberately permit path structure. A test must distinguish those choices from a failure to enforce the owner's permissions, the Workspace boundary, or Quarantine protection. Test recipients, request headers, and Agent Compute parameters too; the single-name rule for paths does not apply to every setting.

Workflow administration and initiation are separate boundaries. Test a Folder Admin's access to v2 configuration, webhook URLs, run records, and manual execution, and a Workspace Administrator's access outside their Workspaces. For Automations v1, test whether each edit by a Folder Admin transfers ownership as documented. For Syncs, distinguish permission to start configured work from permission to administer the connection or access the remote system directly.

Include trigger identity. With inbound email authentication enabled, test messages with an allowed From address that fail domain authentication, through both Incoming Email triggers and Inboxes. Check that File Action triggers respond only to activity in their own site.

TransformScript tests should cover both scripts you author and data those scripts process. Check the limits on running programs, loading libraries or other scripts, and interpreting input as code. Test output escaping in each supported format. Keep testing within the engagement's availability limits and documented exclusions.

For MCP, test application approval, registered redirect destinations, and clients registered while Dynamic Client Registration is disabled. For AI features, compare actions with the actual credential's permissions. Approval of a prompt adds no permission, while a folder named in a prompt does not restrict a credential that has broader access. The testing program's feature exclusions still apply.

File Processing and Storage

Preview, conversion, archive, and encryption features process files supplied by users. Assess whether those processing paths preserve the documented limits on data access and file delivery.

Use test documents, PDFs, images, archives, and GPG data to exercise file processing. Check whether processing can reach another user's or site's data. If a test demonstrates execution beyond the intended processor, stop at the evidence permitted by your engagement and report it.

Test filename and extension rules across uploads, Inbox submissions, renames, copies, moves, Sync deliveries, restores, extraction, and mounted destinations. Compare results with the documented exceptions for whole-folder transfers and archive preservation. Include case, trailing spaces and periods, and differing name rules on remote storage.

For GPG processing, test key selection across Workspaces and the authority required to select any matching key. Remove or expire a required key during delivery and check for files arriving without the required processing. Exercise uploads, copies, moves, and Syncs into mounts with GPG, Auto Unzip, or Malware Scanning enabled, using the storage and buffering rules for the destination.

These features give visitors specific access without granting an ordinary Files.com account. Test the visitor's authority independently of the person who created the link or happens to be signed in to the browser.

For Share Links, test paths, previews, conversions, and changes to the link after its owner loses Share permission. Upload-only and upload-and-download links must preserve existing files when names conflict. Include concurrent uploads and resumed transfers. Full access visitors still cannot create or copy Folder Settings.

Check what each visitor can learn. Upload responses, receipts, and errors must not disclose other submissions, internal folder paths, or link-management details. Compare returned filenames with those the visitor submitted, including when storage rules rename an upload. A previews-only link must not supply the unwatermarked original or another visitor's watermarked preview. For Inboxes, test web and email submission separately, including attachment names that contain folder separators and attempts to view earlier visitors' files.

For invitation access control, use separate browsers and recipients. Test simultaneous use of an invitation, replacement limits, repeated codes, and registration information carried between links. Compare with the documented session and invitation rules.

Public Hosting intentionally serves customer content from a separate origin. Test the sign-in handoff's destination, lifetime, and single-use requirement, and whether hosting access can be used against the administrative application or API. Check protected content from other origins with cross-origin resource sharing (CORS) enabled and disabled, including lookalike hostnames and a null origin. Scripts in hosted content are expected; access to another customer's content or application session is a different result.

Browser Controls

Browser testing should follow supplied data through the product. A filename might appear in a file listing, an administrator's view, a notification, a log, or a watermark. Test those destinations as well as the form where the value was entered, against the documented content-handling rules.

Check that uploaded content cannot run as application code and that a request cannot authenticate using only the cookie portion of the split session token. Test cross-origin requests, return destinations after sign-in, and a public Share Link opened while the browser is signed in as an administrator.

Include embedding. Dedicated Share Link and Inbox embeds are supported, while the main application and API have different framing rules. Test whether an embed exposes administrative functions, a signed-in user's authority, or folder access beyond the visitor's permissions.

Installed Software

Client software connects the Files.com service to a customer's computer. Assess what a remote server, supplied file, or remote configuration can cause the client to do, within the installed-software scope of your engagement.

For SDKs, the CLI, and connectors, test server certificate verification before credentials are sent. Supply remote filenames containing separators, absolute paths, reserved device names, and platform-specific variants, then check where downloads are written. Inspect normal-level logs for credentials and signed transfer URLs.

The Files.com Agent has additional boundaries worth testing:

Transfer authorization limits a signed URL to its path, operation, resource type, and lifetime. Change those values and try the URL against another site or Remote Server you control.
Software updates require release authorization and matching content, platform, and architecture. Test mismatched, stale, and substituted authorizations; possession of the Agent's own credential is not release authority.
Remote management cannot replace host-controlled file roots, permissions, private keys, command definitions, or update policy. Test attempts to change those settings remotely.
Agent Compute runs locally approved commands. Test whether supplied parameter values can select another executable or introduce unintended shell behavior, accounting for the permissions and capabilities of the approved program itself.

For the Local MCP Server, test upload and download paths containing parent-folder components and symbolic links against the configured local root. Distinguish data supplied through the connection from changes requiring prior access to the host.

Product Changes and Public Source Code

For a recurring assessment, review What's New for capabilities added since the previous engagement. Read their documentation and apply the same questions about permissions, credentials, destinations, input handling, and access removal. New features and changed combinations are useful places for a fresh independent review.

The Files.com GitHub organization publishes the CLI, SDKs, MCP server, Terraform provider, and other integration tools. Include relevant source and release changes in your assessment. When a security correction affects one client or operation, consider whether related clients or operations need the same test.

Reporting Findings

Reproduce and verify each finding before including it in your report. Record the relevant reference page and section, the accounts and credential types used, their permissions and configuration, the actions performed, the expected result, and evidence of the observed result. Explain the concrete consequence for access, data, or system behavior.

A difference from the documented behavior should identify the boundary that failed. A concern about a documented design choice should explain its consequence or the requirement it does not meet. If the documentation itself is incorrect or ambiguous, identify that too.

Submit customer assessment results through the agreed process in Customer-Performed Penetration Testing. Independent testers report through the Files.com security testing program under its policy.

Conducting a Penetration Test