Technical Drawing Upload Design for Export Website RFQ Forms

A design guide for the RFQ drawing-upload path on an export website: choose the allowed drawing extensions, order the extension, content-type and signature checks, store the file away from public access, and restrict retrieval to an authorized salesperson. The controls follow OWASP File Upload Cheat Sheet guidance; no single check is treated as proof that a file is safe, and no file-size threshold or implementation detail is invented.

Define the drawing-file acceptance contract before choosing a form field

An RFQ form that accepts a technical drawing is not the same object as a contact form. The drawing is the buyer’s confidential engineering asset, and the moment you add an attachment field you take on three separate obligations: deciding what the endpoint will accept, deciding where the accepted file lives, and deciding who may open it. Those are design decisions, not form-builder settings, and they should be written down before a developer touches the field.

The first obligation is the acceptance contract. Work with the exporter to name the drawing formats the business actually needs to receive. PDF, DWG and STEP are common examples in engineering procurement, but they are examples, not a universal safe list; the correct set is whatever the exporter’s own engineering and sales teams must open to quote. OWASP’s File Upload Cheat Sheet states the governing principle plainly: "List allowed extensions. Only allow safe and critical extensions for business functionality." That sentence is the whole acceptance contract in miniature — the allowlist is derived from the business function, not from what a form plugin happens to permit.

The second obligation is a size policy. OWASP advises to "Set a file size limit," but it does not supply a number, and neither should this article. A drawing set that is normal for one exporter’s product line may be unusable for another. The size limit is an operational decision that belongs to the exporter, informed by what their sales team can realistically download and open, and it should be recorded as a stated policy rather than left to a default.

The third obligation is authorization. OWASP’s principle is "Only allow authorized users to upload files." On a public RFQ form this needs care: the buyer is not a logged-in user of your system, so the practical reading is that the upload endpoint should be reachable only through the intended RFQ flow, with the request itself protected (see the CSRF point in the retrieval section), rather than exposed as a general-purpose file drop. If your site also has a staff-side upload path, that path should require authentication.

One prerequisite sits outside this article: the RFQ form must already deliver a usable inquiry to a salesperson. If that delivery path is not yet sound, fix it first — the launch-time inquiry checks in the website launch SEO checklist cover public access, final URLs and RFQ delivery before release. The drawing-upload design below assumes a working inquiry path and adds a file to it.

Section outcome: a written acceptance contract naming the allowed drawing extensions, a stated size policy, and a decision about who may reach the upload endpoint. Everything in the following sections consumes that contract.

Choosing the allowed extensions for drawings

The allowlist is the primary control on this endpoint, and it should be short. OWASP’s guidance is to allow only business-critical extensions and to avoid any type that is not required. For a drawing-upload field, that means the exporter’s own format set and nothing else — no "any file" option, no convenience catch-all.

Two specific decisions follow from that.

Refuse archives. OWASP states that "ZIP files are not recommended since they can contain all types of files, and the attack vectors pertaining to them are numerous." A buyer who wants to send a drawing package as a ZIP is a real scenario, but accepting the archive moves the content decision out of your control: the archive can carry anything, and your extension check sees only .zip. If the exporter genuinely needs multi-file packages, that is a separate design conversation, not a reason to open the field.

Do not rely on a blocklist. It is tempting to allow everything and block the obviously dangerous extensions. OWASP warns that "blocking specific extensions is a weak protection method on its own," because attackers attempt to bypass such checks. A blocklist can be a secondary layer, but the allowlist is what defines the contract.

What the allowlist should contain is a business decision, not a universal answer. The exporter’s engineering team knows which formats their CAD tools open and which they would have to convert. Ask them, record the answer, and treat any later addition as a change to the acceptance contract rather than a form-field tweak. If the exporter serves multiple markets, consider keeping the format set consistent across language versions unless an explicit market-specific engineering requirement justifies a difference so a buyer in one locale is not offered a different contract than a buyer in another; the consistency problem is the same one described in the multilingual product availability guide, applied here to the upload field rather than to product data.

Section outcome: a short, business-derived allowlist of drawing extensions, an explicit refusal of archives, and a note that the blocklist is not the primary control.

Validation order: extension, content-type, signature

Once the allowlist is fixed, the checks that enforce it need an order, and the order matters. OWASP’s sequence is explicit: "Ensure that input validation is applied before validating the extensions." In practice this means the filename and request are parsed and normalized first, and only then is the extension compared against the allowlist. Validating an extension on a raw, undecoded string is how bypasses slip through.

Extension validation, after decoding. OWASP says to "Ensure that the validation occurs after decoding the filename, and that a proper filter is set in place in order to avoid certain known bypasses." The bypasses it names are worth knowing by name because they are the ones a drawing-upload filter will actually meet:

• Double extensions such as .jpg.php, which slip past a naive regex looking only for .jpg.
• Null bytes such as .php%00.jpg, where the trailing part is truncated and the earlier extension becomes effective.
• Case manipulation such as .pHp, which defeats case-sensitive blocklists.
• Alternative extensions that a server may map to the same interpreter depending on configuration.
• Windows NTFS alternate data streams, where a colon acts as a stream separator. OWASP’s instruction is direct: "reject any filename containing a colon ( : )."

A drawing field that accepts .dwg and .step still needs this discipline, because the filter is comparing strings and the attacker is choosing the string.

Content-Type is a hint, not a control. OWASP is unambiguous: "Validate the file type, don’t trust the Content-Type header as it can be spoofed." The header is supplied by the client. It is useful for catching a buyer who accidentally attached the wrong file, and it is useless as a security boundary.

Signature validation is one layer, not the layer. Checking the file’s signature against the expected type is a reasonable additional check, but OWASP cautions that "This should not be used on its own, as bypassing it is pretty common and easy." A drawing that passes a signature check has not been proven safe; it has passed one check.

The reason to stack these rather than pick one is stated at the top of OWASP’s protection section: "There is no silver bullet in validating user content. Implementing a defense in depth approach is key… Implementing multiple techniques is key and recommended, as no one technique is enough to secure the service." For the RFQ drawing field, that means the allowlist, the decoded-extension check, the content-type hint and the signature check are layers of one filter, not alternatives to each other.

Section outcome: a defined check order — parse and normalize, then extension against the allowlist, then content-type as a hint, then signature as an additional layer — with the named bypasses explicitly handled.

Storing the drawing away from public access

Where the accepted file lands is a separate decision from how it was validated, and it is the one that most often goes wrong on a small export site, because the default is to drop uploads into a folder under the web root where the web server will happily serve them to anyone who guesses the path.

OWASP’s storage guidance is ordered by security priority. The preferred option is to "Store the files on a different server. If that’s not possible, store them outside of the webroot." A drawing that lives outside the web root has no public URL at all, which is the property you want for a confidential engineering file. If the file must sit inside the web root, OWASP’s next instruction is to "set them in write permissions only," and if read access is required, "setting proper controls is a must (e.g. internal IP, authorized user, etc.)."

If the file is ever publicly retrievable — which for a confidential drawing it should not be — OWASP’s pattern is to "use a handler that gets mapped to filenames inside the application (someid -> file.ext)." The public identifier is an opaque ID, and the application resolves it to the real file after checking authorization. That pattern is also the cleanest way to serve a drawing to a logged-in salesperson without exposing a guessable path.

One threat belongs specifically to the upload directory and is easy to overlook: OWASP warns that "an attacker may attempt to upload a web server configuration file (e.g. .htaccess, web.config) into the upload directory." If the upload directory is inside the web root and the server honors per-directory configuration, a file that lands there can change how the directory behaves. Keeping uploads outside the web root, or on a separate host, removes this class of problem rather than mitigating it.

A related filename decision belongs here too, because it affects what lands on disk. OWASP recommends to "Change the filename to something generated by the application" and to "Set a filename length limit. Restrict the allowed characters if possible." Generating the stored name server-side means the buyer’s original filename is metadata, not a path, and the colon rule from the previous section is enforced at the same point.

Section outcome: a storage decision — separate host, or outside the web root, or inside the web root with write-only permissions and controlled read access — plus a server-generated stored filename and an explicit awareness of configuration-file uploads into the upload directory.

Authorize drawing retrieval and treat scanning as one limited layer

The last decision is who can open the drawing once it is stored, and what a scan of that file does and does not establish.

Retrieval is an authorization decision. OWASP’s upload principle — "Only allow authorized users to upload files" — has a retrieval counterpart in the storage guidance: if read access is required, proper controls such as an authorized user are a must. For the RFQ drawing, that means the salesperson’s access should be an authenticated action against the application, not a URL that happens to be unlisted. An unlisted URL is not an access control; it is a URL that has not been shared yet. If the drawing is served through a mapped handler, the handler is the place to check that the requesting user is the authorized salesperson before it resolves the ID to a file.

Scanning is conditional and partial. OWASP’s guidance is to "Run the file through an antivirus or a sandbox if available to validate that it doesn’t contain malicious data." Two words in that sentence carry the weight: *if available*, and *validate*. A scan is a layer that may or may not be present depending on the stack, and a clean result means the file did not match what the scanner looks for — not that the file is safe to open. OWASP’s broader position is the reason: "There is no silver bullet in validating user content," and multiple techniques are recommended because no single one is enough. A drawing that passed the allowlist, the extension check, the signature check and a scan has passed those checks; it has not been proven safe, and the salesperson opening it is still opening an untrusted file.

Protect the upload request itself. OWASP’s checklist includes "Protect the file upload from CSRF attacks." CSRF protection does not establish an uploader’s identity or permission. Define upload authorization separately; do not treat an anonymous form with a CSRF control as equivalent to an authorized-user upload flow.

Provide a reporting path. OWASP also advises that "The File Upload service should allow users to report illegal content, and copyright owners to report abuse." For an export site, a practical recommendation is to state how a user can report suspected abuse. This follows the OWASP design guidance; it is not a claim about a legal obligation.

What this section deliberately does not do is claim that any of these controls makes the upload safe, or that a specific implementation was tested. The controls are design decisions drawn from OWASP guidance; whether a given site implements them correctly is a separate question that only that site’s own testing can answer. If the inquiry path that carries the drawing to the salesperson is still being validated, the form-to-CRM handoff checks in the bilingual B2B export website review cover that layer, and this article’s scope ends at the file itself.

Section outcome: an authenticated retrieval path for the salesperson, a clear statement that scanning is one conditional layer rather than a safety guarantee, CSRF protection on the upload request, and a reporting path for illegal or infringing content.