Dragwyb Docs Dragwyb Docs
Visit Website
Updated on Oct 18, 2026

Validate Uploaded Attachments

Review the file field’s actual server-side checks, size and MIME restrictions, and the current gaps in upload transfer and storage.

This guide describes the server-side checks found in Smart Form Builder by Dragwyb 1.3.6. It is important to distinguish validation from a complete upload workflow: the inspected code checks PHP’s uploaded-file data, but the normal frontend submission handler sends JSON and no file-move or persistence routine was found in the inspected submission path.

Checks performed by the field

  • Checks that the configured field exists in the form configuration.
  • Checks whether a file was selected when the field is marked required.
  • Rejects PHP upload errors other than a successful upload.
  • Rejects files larger than 1 MB.
  • Checks the filename extension against JPG, JPEG, PNG, PDF, DOC, DOCX, and TXT.
  • Checks the detected MIME type against JPEG, PNG, PDF, and plain text.
  • Sanitizes the filename returned as the field value; that is not the same as moving or securely storing the file.

Known mismatches and limitations

  • The editor notice advertises a 2 MB maximum, while server-side validation enforces 1 MB.
  • DOC and DOCX appear in the extension list but their common MIME types are not in the MIME allowlist, so valid documents may be rejected.
  • The rendered file input accepts the listed extensions, but client-side accept attributes are not a security boundary by themselves.
  • No complete transfer/storage implementation was found in the inspected submission path. The source does not establish a secure upload directory, download permissions, attachment cleanup, or a stored attachment URL.

How to verify after implementation is corrected

  1. Test a small PNG or PDF that is below the enforced size limit.
  2. Test a file over 1 MB and an extension outside the allowed list; confirm both are rejected server-side.
  3. Test DOC and DOCX separately because of the MIME allowlist mismatch.
  4. Confirm a successful upload is stored in a controlled location, the submission only records a safe reference, and unauthorized visitors cannot fetch private files.
  5. Confirm deletion and retention procedures remove stored files when appropriate.

These are recommended verification steps, not claims that those live tests have already passed. Do not use the current field as a production file-storage feature until transfer, persistence, and access controls are implemented and verified.

Screenshot to add: [File upload validation and restrictions]