Files.com

Files.com has run this program since 2017 because independent researchers help us find security problems we would otherwise miss. The range of experience and approaches in HackerOne's community is valuable to us, and we believe that work matters even more as AI becomes a routine part of security testing.

We want the best researchers working on Files.com, and we aim to pay at the top tier of HackerOne programs. Our rewards range from $250 to $50,000 USD per valid report, based on severity and the value of the finding, at our sole discretion. Our analysis of Q3 2026 data showed that we paid more in bounty dollars per report received than most of the best-known programs on HackerOne, including HackerOne's own. We accept valid findings and pay fairly and promptly when researchers follow the program rules.

Important Terms

This policy is the contract for participation in the program. Read it in full before testing Files.com or submitting a report. Read the material relevant to your report in the Developer Docs, Security Reference, and reference sections of the product documentation. These sources describe the behavior, permissions, and protections against which we evaluate findings.

Authorized Scope

You may test the assets listed as In Scope on this page. When testing a hosted Files.com site, use trial sites you registered yourself for this program or sites explicitly listed as In Scope.

Do not attempt any testing against Files.com customers. No testing of any kind is ever authorized against their sites, accounts, or data. Any other subdomain.files.com address may belong to a customer; do not scan, probe, attempt to access, or otherwise test it.

Other Files.com domains, subdomains, and properties, including those belonging to affiliated entities, are outside this program unless listed as In Scope. The Out of Scope list is not comprehensive, so an asset's absence from that list does not authorize you to test it.

Do not submit reports about out-of-scope assets through this program. We treat such a report as evidence that the program rules were not followed, even if the finding is serious or you are not requesting payment. HackerOne's Gold Standard Safe Harbor and AI Research Safe Harbor both depend on testing within the program's authorized scope; neither covers testing against an unlisted asset. If you need to tell us about something that cannot be submitted under this program, contact [email protected].

How To Test

Start a Free Trial at Files.com to create your own testing site at your-assigned-subdomain.files.com. The Company Name field must contain [BUGBOUNTY], including the brackets and with no space, and the work email must be your HackerOne alias, [email protected]. These identify the trial and help us distinguish your testing from customer activity. For example:

• Company name: [BUGBOUNTY] Trial Company
• Phone number: 555-555-5555
• Work email: [email protected]
• Password: Pa55w0rd

A trial is only registered for this program if its Company Name contains [BUGBOUNTY] and its work email is your HackerOne alias. Testing on a trial not registered for this program will result in a ban from the program the first time it happens, and a finding reached that way is not eligible for a bounty, however serious it is.

You may register up to four trial sites per researcher in any rolling 90-day period, across all email addresses and accounts you use. Deleting a site does not restore the allowance. Test users created within those sites do not count toward this limit.

A trial identified with [BUGBOUNTY] and your HackerOne alias can turn on every feature and is never prompted for payment during testing. Do not enter payment card information or make a payment unless you intend to pay the charge in full. The Terms of Service you accept when creating the account remain binding and affect your rights, so read them before proceeding.

Testing of hosted Files.com sites must remain on trial sites you registered yourself for this program or sites explicitly listed as In Scope. Use test users and data you created. Do not attempt to access anyone else's accounts or data, or affect anyone else's use of the service. Testing against any customer's site will result in a ban from the program the first time it happens, and a finding reached that way is not eligible for a bounty, however serious it is.

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

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 trial 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.

For every endpoint, compare the Authorization Requirement in the Developer Docs with the result for each account and credential, as The API Is Wider Than the Web Interface describes. 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.

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.

If you encounter customer data while testing your own trial site, stop testing that path. Use redacted request and response excerpts, timestamps, and non-sensitive request identifiers to explain what happened. Do not include customer data in the report or send it to an AI provider or other third party. Delete every copy of the customer data you hold, including any captured in logs or screenshots. Do not continue to investigate how much data is accessible.

To demonstrate code execution, use only a harmless check that returns a fixed string or a simple arithmetic result. Once execution is confirmed, stop and report the finding. Do not use code execution to read system files, environment variables, credentials, or customer data; change files or settings; establish a shell or persistence; or make further network connections. Leave system enumeration, further escalation, and exploration of other systems to Files.com.

This policy has three stopping rules. Stop testing a path when you encounter customer data. Stop once code execution is confirmed. Stop after the one authentication check allowed on an exposed Files.com credential. These rules exist so that proving a finding never puts a customer's data or our systems at risk. Past those points, we can finish the work safely and you can't, so we take it over.

When a stopping rule prevents further validation, report what you safely verified and explain what remains untested. Files.com will investigate the remaining impact internally and use the impact we confirm to determine severity and payment. Following a stopping rule does not reduce the value we assign to a finding. You must not access customer data, explore a working exposed credential, or perform any other prohibited action to establish a higher severity or payout.

Nothing else is a stopping rule. When a Files.com protection rejects, blocks, or times out your request, it didn't stop your testing. It answered it. Getting past that protection is the research we pay for, and a report that hands it to us to finish hasn't found anything yet.

Protect the reliability and integrity of the service and its data during testing. Denial of service, spam, and any other attacks that could harm them are prohibited. Social engineering, phishing, and physical attacks against employees, users, or infrastructure are also prohibited.

Limit automated testing to a combined maximum of two requests per second across all in-scope assets. This is one limit per researcher, shared by all scanners, scripts, AI agents, accounts, IP addresses, and people or services acting on your behalf. Pace requests evenly and stop if your testing degrades service performance or availability.

The in-app AI Assistant is out of scope and must not be used during testing. Requests to that feature incur costs for Files.com.

Professional Conduct and AI Use

You may use any reasonable AI provider for research and writing, provided you have ensured that its terms, settings, and handling of your material comply with this program's requirements. Your providers must not disclose information or take any other action that you are not permitted to take under these terms. You are responsible for the actions of your AI providers, subcontractors, and subprocessors, including any further providers they use. That responsibility covers confidentiality, authorized scope, testing limits, stopping rules, and every other requirement of this policy.

You also remain responsible for everything you submit. Instruct your tools to read this policy and the documentation relevant to your report. Before submitting, read the entire report yourself, verify its claims and reproduction steps, and remove repetition, unsupported assertions, and unrelated material. Clearly identify anything you could not validate because this policy required you to stop testing.

Our security team spends real time reviewing every submission. We receive too many reports that leave our team to separate invented claims from evidence, find the actual issue in pages of generated text, or reconstruct steps the reporter has never verified. That research, verification, and editing belong to the reporter. Passing the work to our team abuses the program and takes time away from investigating legitimate findings and fixing security problems.

Reports that plainly read as unreviewed AI output are closed as Spam, even when they contain correct information. Including a real finding somewhere in a mass of unreviewed material does not excuse the submission. These egregious failures to prepare and review a report are subject to the enforcement measures below.

Being professional, precise, and pleasant to work with is a condition of participation. Violations of the program rules, including reports based on assumptions or undocumented expectations and unprofessional conduct, result in immediate report closure, negative reputation points, reporter bans, and escalation to HackerOne. If you believe a report violates these rules, do not submit it.

What Counts

We pay for reproducible vulnerabilities in in-scope Files.com assets that allow someone to access data, take actions, or control systems beyond the authority they have been given. We also pay when a security protection we document, such as encryption or credential validation, fails to work as described.

Eligible findings include:

• Authentication failures that allow account takeover or bypass login, SSO, or two-factor authentication. This includes failures in the handling of sessions, tokens, and one-time codes that allow someone to authenticate when they should no longer be able to, or as a different user.
• Authorization failures that allow someone to read, change, or delete data, or perform an action their permissions do not allow. These include failures in isolation between users or sites, as well as bypasses of controls on Share Links, Inboxes, and registration flows.
• Unauthorized code execution, access to restricted server files, or access to internal services. Injection, path traversal, unsafe deserialization, and SSRF qualify when the report demonstrates the resulting access or control.
• XSS that runs in another user's security context, or CSRF or clickjacking that causes an unauthorized change to data or settings.
• Exposure of sensitive information to someone who is not entitled to it, including files, metadata, audit logs, personal data, and secrets in logs or error messages. Publicly exposed Files.com credentials are also eligible under the conditions below.
• Failures in our client software's handling of untrusted data, such as writing outside the folder the user selected, failing to validate a server certificate, accepting an unsigned update, or sending credentials to the wrong destination.

These examples are not exhaustive. Other vulnerabilities, including business logic flaws, qualify when they demonstrate a security consequence under the same standard. Issues involving billing, pricing, or the cost of using the service are excluded.

Findings must establish what access or control the vulnerability adds beyond the permissions already held. Explain which permission or protection failed, and demonstrate the claimed result within the testing authorized by this policy. If a stopping rule prevents further validation, follow the instructions under How To Test; Files.com will validate the remaining impact internally. Scanner output, a suspected weakness, or a hypothetical chain of further vulnerabilities is not enough. The Documented Behavior section below explains how to establish the expected protection, and the exclusions and severity caps elsewhere in this policy still apply.

Demonstrate issues involving multiple users or sites using only test users and trial sites you created. Customer sites, accounts, and data must never be used to demonstrate impact.

Documented Behavior

The expected behavior must come from a source we can evaluate. For Files.com, use the relevant sections of the Developer Docs, Security Reference, and reference sections of the product documentation. Our security page, compliance documents, and feature documentation can also establish a protection we have committed to providing. Cite the page that describes the relevant permission or protection, then show how the behavior differs from it.

We close reports as invalid when they rely on assumptions about what the product should do, appeals to best practice, or comparisons with other products rather than a documented requirement.

A setting or protection covers the feature its documentation describes. It doesn't cover a different feature because the two look alike, sit on the same screen, or serve a similar purpose.

Features check different things at different times because they do different jobs. A webhook's address is fixed, so we validate it before the webhook is saved. An Import File URL can be built from workflow data on every run, so we check its destination each time the request is made. The MCP Dynamic Client Registration setting governs clients that register themselves. It has never governed clients that identify themselves with a Client ID Metadata Document, and our MCP documentation says so.

Reports that take a setting or check documented for one feature and expect it to govern another are among the most common we receive, and among the most frustrating. The page for the feature you actually tested answers them. They close as invalid.

Some findings concern a security rule established by another platform. Examples include an operating system's separation between users, a browser's separation between websites, TLS certificate validation, or the access rules defined by SFTP, FTP, and WebDAV. If Files.com software violates one of those rules, cite the platform's rule and demonstrate the violation. Behavior that the operating system, browser, or protocol is designed to allow is not a finding against Files.com.

The API Is Wider Than the Web Interface

Files.com is built API-first. Every capability goes into the REST API first, and the web interface, the Desktop App, and our protocol servers are all built on that same API.

The web interface is one client of the API, built for people working interactively. It shows the controls that make sense for that work, in the places and for the roles where they make sense. It doesn't show everything the API can do.

So the API is always at least as wide as the web interface, and in places it's wider. You can't predict where from the web interface. The API takes parameters that have no field on screen. It offers operations that have no button. It lets a role call an endpoint the web interface never shows that role. FTP, SFTP, WebDAV, the SDKs, and the CLI also reach functionality the web interface doesn't present.

That's why the web interface can't tell you what a user is allowed to do. Our service enforces authorization for each operation and credential, and the Developer Docs state who may call each endpoint in its Authorization Requirement. A missing button, a disabled control, a limit the web interface checks before it sends a request, or a confirmation step it adds is a choice about the interactive experience. None of them is a permission, and a request that skips them is not a bypass.

We close reports as invalid when their expected behavior comes from the web interface. If you believe a role can do more than it's allowed to, cite the Authorization Requirement for the endpoint or the documentation for that role, then show the API allowing more than that page does.

Exposed Files.com Credentials

A working Files.com credential, key, or token exposed publicly is eligible if it belongs to Files.com rather than a customer and we were not already aware of the exposure. Its severity depends on the access it provides.

You may make one minimal authentication check if the public source clearly establishes that the credential belongs to Files.com and the target is listed as In Scope. The check must return only authentication status or the authenticated identity, without listing resources, retrieving files or other data, or modifying the account or service. Whether the check succeeds or fails, stop. If it works, report the credential together with where you found it and the check you performed. Do not use the resulting session or explore the credential's permissions; Files.com will determine its access internally.

If ownership or scope is uncertain, or you cannot check the credential within those limits, do not test it. Report the exposure through HackerOne with the credential's source, the evidence linking it to Files.com, and an explanation of what you could not safely validate. Files.com will validate it internally. A credential must be confirmed to work, either through the permitted check or by Files.com, to be eligible for payment. Speculation that a credential might exist or provide access is not enough. Customer credentials are excluded and must never be tested.

What We Want Tested

Our own security testing combines automated scanning, independent penetration tests, and ongoing product security testing. A submission limited to port scans, scanner output, and standard web application checks largely repeats that work.

The most useful 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 knowing what the documentation says the product permits. Test every area below, including combinations and variations we have not listed.

A failure of any boundary below is a finding under What Counts. Severity reserves Critical for platform-wide and cross-customer findings, so tests that cross from one customer's site to another's carry the largest rewards.

This section describes where we want testing. It authorizes nothing beyond Authorized Scope and How To Test, and the exclusions under What Does Not Count still apply.

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 trial sites, 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 you own and subdomains your own trial sites used, 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 the request limit under How To Test.

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 trial site 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. In app sign-in tests, 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.

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 must stay absent.

Keep independently authorized work distinct from continuing account access. Signed transfer URLs have their own lifetimes, described under Transfer URLs After Access Changes, 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. A request arriving at a server you configured is the feature working, as Outbound Requests to Addresses You Choose explains. 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 and TransformScript

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.

Automations v2 Template Braces explains the double-brace and triple-brace forms in path fields. Destination Path Replacement, like triple braces, deliberately permits path structure, and Automation Inputs Chosen by an Administrator covers the other settings an administrator lets data control. A test must distinguish those choices from a failure to enforce the owner's permissions, the Workspace boundary, or Quarantine protection.

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.

Cover both the TransformScript scripts you author and the 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 this testing within the denial-of-service prohibition, the request limit, and the code execution stopping rule under How To Test.

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, follow the code execution stopping rule under How To Test 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.

Share Links, Inboxes, and Public Hosting

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, as Scripts on Public Hosting explains; access to another customer's content or application session is a different result.

Browser Controls

In browser testing, 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. Findings that require access to the affected machine are excluded under Local Access and Third-Party Software.

For the SDKs and the CLI, 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. Names that differ only by a trailing period or space are covered under Trailing Periods and Spaces on Windows. 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.

Product Changes and Public Source Code

Review What's New for recently added capabilities. 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 and SDKs. Include relevant source and release changes in your testing. When a security correction affects one client or operation, consider whether related clients or operations need the same test.

What Does Not Count

HackerOne's Core Ineligible Findings list applies to this program. The following rules address Files.com specifically.

Common False Positives

We receive these reports again and again. Each one describes documented behavior, and each closes as Not Applicable.

Site Administrators on Their Own Site

A Site Administrator has every permission on their own site, because the site is theirs to run. Using that role's documented administrative capabilities is not a security finding.

Read-Only Site Administrators

A Read-Only Site Administrator can see anything a Site Administrator can see, including credentials, keys, tokens, logs, and other sensitive information in administrative records. The role is meant for people trusted nearly as much as a Site Administrator, and we evaluate it that way, so a report whose finding is that this role can see something a Site Administrator can see is not a security finding, however the report describes what was seen. We are skeptical of reports that use the role to make something meant for Site Administrators look more dangerous, and we do not appreciate that approach. The role does not grant access to every file or folder: file contents remain subject to the user's folder permissions.

Folder Administrators and the User Directory

Folder Administrators can see all users and groups on the site, including people with no access to their folders. That's intentional, because a Folder Administrator has to be able to find the people and groups they want to grant access to or notify. Seeing an account doesn't grant permission to edit it or read its files.

Folder Administrators and Their Folder's Settings

Folder Administrators have full control over the Folder Settings on their folder, including its webhooks, notifications, and the integrations attached to it, so they receive each setting's full configuration, credentials included. A Folder Admin whose permission starts below the folder where a setting is configured gets a limited view without the credentials, so they can understand the rules they inherit without receiving credentials for integrations they don't administer. Reading the configuration of a setting you're allowed to change is not a finding.

Allow Users To Create API Keys

The Allow Users To Create API Keys setting controls whether users can create keys for their own integrations. It doesn't restrict deleting or managing keys. It also doesn't stop the Desktop App and Mobile App from receiving their own credential when a user signs in, because those apps need one to stay connected.

FTP, SFTP, and WebDAV Servers

Files.com hosts FTP, SFTP, and WebDAV. An FTP server listening on port 21, an SFTP server on port 22, or a server answering WebDAV verbs is the product working.

The Public Settings Endpoint

GET /api/rest/v1/settings (or settings.json) is public on every site. Without credentials, it returns the settings the web interface needs before anyone signs in, and nothing in that response is confidential. A report that this endpoint answers without authentication, or that any site's public settings can be read the same way, describes the endpoint working. A finding here has to show a credential receiving more than it's allowed to.

Scripts on Public Hosting

Public hosting at https://subdomain.hosted-by-files.com/folder_name/ is full web hosting, including JavaScript, so a script you upload to your own hosted folder is supposed to run. The hosting domain is kept separate from the web interface and API, so a hosted script doesn't inherit a signed-in user's access. XSS in public hosting is in scope only when it lets one customer attack another.

Files Stored as Uploaded

Files are stored exactly as uploaded. We don't remove EXIF metadata or otherwise change their contents.

CSV Injection

CSV injection is not eligible, in any export. We believe most people use CSV files with ERP systems and code, not with Microsoft Excel. A spreadsheet that runs a cell as a formula when it opens a CSV file has a bug of its own, and our History and notification exports keep every value exactly as recorded rather than bend the file format around that bug. Report it to Microsoft. HackerOne's Core Ineligible Findings list excludes CSV injection too.

Symlinks

Files.com doesn't create or store symlinks. A link on your machine, or on a remote server connected to Files.com, points wherever the person who made it pointed it. Symlinks are not a vulnerability unless they result in unauthorized access or privilege escalation.

SDK Debug Logging

At the SDKs' debug logging level, all transport data is recorded without redaction, so debug output may contain sensitive information. That's what debug logging is for.

Automation Inputs Chosen by an Administrator

An Automation does what its administrator built it to do with the data it receives. File names, metadata, webhook fields, and email subjects can all carry values chosen by someone else, and the administrator decides which of those values may control the workflow, whether that's a destination path, a Send Email recipient, an Import File URL or header, or an Agent Compute argument. A webhook caller holds a URL that works as a credential, handed to them by that administrator. When an administrator puts an outside value into a setting and the Automation sends, fetches, writes, or runs what that value says, that's the workflow they built. Where a documented check applies to a value, such as the double-brace rule below, a value that gets past the check is a finding.

Automations v2 Template Braces

In Automations v2, triple braces, {{{ }}}, are the explicitly unescaped template form: the value is inserted into the path as written, separators and .. segments included, and the prefix around it confines nothing. An administrator who writes {{{ }}} has chosen to let that data supply part of the path, so we do not accept traversal or injection reports built on it, whatever the data's source. Double braces, {{ }}, are the escaped form: one folder or file name, with a value carrying a separator or equal to ., .., or empty failing the item. Which name a {{ }} value selects is the administrator's business rule. A {{ }} value that still changes a path's folder structure is a documented check failing, and that is a finding under What Counts.

Outbound Requests to Addresses You Choose

Files.com connects out to systems our customers choose, through webhooks and their delivery test, Event Channel targets, Remote Servers, Import File, SSO metadata, MCP client metadata documents, and Custom SMTP. Those requests come from our published IP range, and Files.com won't send webhooks, Event Channel deliveries, or Import File requests to private, loopback, or link-local addresses. When you point one of these features at a server you control and a request arrives from our range, the feature is working. That isn't server-side request forgery. An SSRF finding starts with a response from an internal address.

Clickwraps on Share Links and Inboxes

A Clickwrap records that a person agreed to terms, so we show it only in the web interface, and a Share Link allows file transfers only through its web page. That page shows the visitor the Clickwrap and keeps its text, the visitor's IP address, and the time with their registration. The requests the page sends to record a registration aren't part of our published API, and our Developer Docs document listing Share Link and Inbox registrations, not creating them. A request you write yourself that leaves out the agreement, or sets it to false, is not a visitor declining the terms on the page, and it isn't a Clickwrap bypass.

Trailing Periods and Spaces on Windows

Files.com keeps report.txt, report.txt., and report.txt (with a trailing space) as separate files, and Windows doesn't allow names that end in a period or a space. When the CLI or an SDK downloads them on Windows, it writes to the path Windows resolves, so all three land on one local file and the last one written stays. Folder permissions control the files on Files.com, which stay separate, not the copy Windows writes to someone's disk.

Transfer URLs After Access Changes

Uploads, downloads, and previews run on signed URLs that expire. They let file data move without a full permission check on every request, which keeps transfers fast. Removing someone's access, or ending their session, stops new URLs, and a URL already issued works until it expires: up to 3 minutes for a download, 15 minutes for an upload, and up to 3 hours for a preview. An Agent transfer URL isn't tied to the IP address that requested it, either. Treat the complete URL as sensitive.

AS2 Auto Validation

Auto, the default signature and MDN validation level for a new AS2 trading partner, is a setup state. It reads the partner's next message to find the highest level that partner supports, and that level replaces Auto from then on. An unsigned first message sets the signature level to None, and as we said when we released it, "The next message always passes validation." An administrator who needs signed messages from the very first one sets the partner to Normal.

MCP Dynamic Client Registration and CIMD

The MCP Dynamic Client Registration setting governs Dynamic Client Registration, where a client describes itself to get a client ID, and nothing else. It's off by default, and we tell customers to turn it on only for clients that need it. A DCR client's description proves nothing about who published it. The setting doesn't restrict clients that use Client ID Metadata Documents, it doesn't disconnect clients already authorized, and with it off, a registration request still returns a client ID that can never complete sign-in. Neither method grants access on its own: a person signs in and approves the client, which then holds an ordinary login session for that person.

Local Access and Third-Party Software

We exclude findings in the Desktop app, CLI, Agent, Mobile app, SDKs, or MCP server that require the person exploiting the issue to already have access to the affected machine. This includes escalation from one local user to another or to administrator or root, as well as findings requiring local code execution, binary modification, or a non-default installation location. The macOS multi-user and Mac Quarantine cases fall within this exclusion. This is an intentional limit of the program, even if a change to our software could prevent the behavior.

Defects in an underlying operating system itself are outside this program. The Files.com Editor uses OnlyOffice. Defects that require a fix in OnlyOffice itself should be submitted to OnlyOffice's program.

Security failures in the way Files.com integrates, configures, or deploys third-party software are eligible when they meet this program's other requirements. For example, a known vulnerability may qualify if it remains exploitable because a Files.com deployment is missing an available upstream fix. A finding can qualify even if only one server or container is affected. The report must demonstrate the security impact through authorized testing; an old version number or a missing patch alone is not enough.

A customer's exposed credentials are the customer's responsibility and do not constitute a Files.com vulnerability.

Other Excluded Findings

Func