Payments are experiencing issues due to temporary restrictions in Russia. If your payment does not go through, please submit a support request.Our support team is available 24/7 — we are always here to help with hosting and server issues.We are now accepting requests for dedicated server rental and colocation services in our data center.Reminder: we recommend enabling backups for additional data protection.A new VPS/VDS lineup with NVMe storage and improved performance is now available.Maintenance work on some servers has been completed. All services are operating normally.
Article3 min read

Photos in Reviews and Order Attachments: Securely Handling File Uploads on 1C-Bitrix

The BitrixFramework documentation describes the Uploader subsystem. I examine what limits an online store needs to ensure convenient file uploads do not create access or storage issues.

A customer photographs a damaged package
In this article

A photo explains the issue faster than a long message. A buyer can show a damaged package, include product dimensions, or send a print file. However, adding an upload button imposes a new obligation on the site: to accept external files and handle them correctly.

On September 16, 2026, the BitrixFramework documentation published an article on the Uploader subsystem. It covers file reception, temporary storage, validation, and subsequent processing. The mere existence of this subsystem does not mean that any custom form handler is already secure.

Determine which files are actually needed

Rules for a review photo differ from those for a print shop layout. If a store accepts only images, allowing any file type adds risk without benefit. Limits should be set on individual file size, the number of files, and the total upload volume.

Browser-side validation helps users spot errors quickly, but the server must independently verify the data. The user interface can be bypassed, and a file extension in the name alone is insufficient to determine the file's contents.

For a store owner, this translates to a specific development requirement: unsuitable files must be rejected before they become accessible to others, while the buyer receives a clear message. This must be achieved without technical complications or the loss of already filled form data.

Not every attachment needs to be public.

A product photo in a published review may be intended for all visitors. In contrast, an invoice, blueprint, or image attached to a complaint is typically needed only by a limited group of employees. Storing these materials in a single publicly accessible location is convenient only until the first mistake occurs.

Verify access from another account and without authorization. Can an attachment to someone else's order be opened if its URL is known? What happens after the inquiry is deleted? These questions are more important than how attractive the file drag-and-drop zone looks.

If the form allows sending data in parts, temporary fragments also require cleanup. A user might close the page, causing the upload to abort, leaving disk space occupied. The retention period for incomplete uploads must be defined in advance.

Test inconvenient but common scenarios

Acceptance testing should include large photos from a phone, multiple sequential files, non-standard filenames, and connection interruptions. There is no need to hunt for exotic attacks to discover that resending creates duplicates or that an error wipes out a buyer's comment.

I would also clarify who monitors storage capacity and how an employee reports a suspicious attachment. This way, file uploads become a full part of customer service: it is convenient for the buyer to explain the task, and the store knows where the materials are and who can view them.

Discussion0

Share your experience and ask questions. Comments without links appear after editorial review.

No comments yet. Start the discussion.