Are you aware that the security you may apply to your site's pages, whether through content type access restrictions or the CAS firewall, does not apply to the documents you associate with them? If search engines keep finding files you want to protect, keep reading to understand why this happens and how to avoid it.

Why are files handled differently?

First, in Drupal's eyes pages (known as "nodes") and files (images, media, and other documents you upload) aren't the same kind of content. Second, as a result of the first, they're stored in different locations. Pages are stored in your site's database—collections of structured content from the fields you've filled in related to a specific node, while files uploaded are stored in a folder in your site's directory structure.

The File Folder is Public

By default, the configuration setting for the folder that stores the files on your site is set to "Public," meaning its contents are publicly available to everyone and not restricted by user account permissions or some form of site security. The reason for this is the vast majority of sites are intended for public viewing, so no special settings need to be invoked. In fact, making that folder "Private" could cause issues with files and images not displaying if, say, the person viewing your pages doesn't have an account on your site they can log into. Not ideal for most site owners.

Relationships are part of the Database

We've established that nodes are stored in the database and files in their own separate folder, but what about the connection between them? When you insert an image into a node or embed a link to a file in your page's text, the site records that relationship reference as part of the node in the database. This reference is then maintained and included as part of your site's revision history. This is going to be important in a moment, so stick a pin in this section.

How this Relates to Securing Your Files

While not common, we do have a small number of full intranet sites, usually hidden behind CAS, or hybrid sites that use a custom content type and the Node View Permissions module to cordon off specific page content from the public to be viewed only by approved account holders on the site. In this scenario, as described above, files are still public. While technically any files linked to secure content in either scenario are obfuscated, the loophole occurs when you or your fellow account holder share the direct link to a file such as a .pdf or .docx with the full pathway.

Example: https://sitename.ucdavis.edu/sites/g/files/dgvnsk001/files/2024-01/310-70.pdf

When you share such a link in an email or paste it somewhere else that's outside of the node itself, it's now possible for that link to be discovered by search engines. Hence why some of our users have contacted us in a panic when they discover the file link in search results pointing directly to sensitive file content that was never meant to be publicly available. 

Webform uploads are an exception; content uploaded to webforms are private and secure, and protected by Drupal's access control system. These are never in the public sphere, even if someone has a link to the result entry and the associated file upload.

How to Keep your Files Secure

You can avoid the above scenario by never sharing the direct link to a file. Instead, share the link to the page that contains the link to the file. The page is protected either through CAS or via your custom permission settings, so unless the recipient has the correct privileges to access that page, they won't ever see the file.

Can you rely on this method? Depends on whether or not everyone who interacts with your page understands how the site's security works in the first place. If you're now feeling a sinking feeling in the pit of your stomach as you consider the implications, then you need to weigh how important your files' security truly is because the human element in this specific situation will always be a variable beyond your control.

It's also one of the reasons our users wind up relying on Fancy File Delete and a Fastly cache purge to help permanently remove such files that have been indexed by search engines. Other reasons can include improperly replaced files and files that were once okay for public consumption but may need to be urgently removed for health or legal reasons.

We would also like to remind you that SiteFarm is only rated for security levels P-1 and P-2, per UCOP's IS-3 electronic security policy, and certain types of information and data are prohibited from being collected and stored on a SiteFarm site as a result. If you need a refresher or aren't familiar with this policy at all, please read our article Information Security Practices for SiteFarm.

For truly secure files, upload your files to UC Davis' Box.com service and then link to the file at that location. This solution places the security restriction in front of Box and you'll have more options for how you define who can view, edit, and access your file content. Check out our additional information and training documentation to help you protect your file content with confidence.