Manufacturing Website Design: Keep RFQ Files Private

Manufacturing website design should keep a buyer's private RFQ files accessible only through the agreed, authorized workflow. Hiding a download button is insufficient if the original file, its preview, or a notification link can still be opened by someone who should not receive it. Make the file itself part of the website acceptance test.

This guide helps small US manufacturers scope drawing and attachment handling for requests for quotation. The same questions apply to factories in India and other markets. It extends our RFQ receipt guide, which checks whether an inquiry arrived. Here the question is who can retrieve each attachment afterward.

Decide what belongs in the upload workflow

A public capability brochure and a buyer's private part drawing serve different purposes. Keep their publishing decisions separate. The public-download review guide covers approved marketing files; an incoming RFQ attachment should not automatically enter that public library.

List the information your team actually needs at the inquiry stage. A simple contact form can start a conversation before an approved private transfer route is arranged. If uploads are included, define who can submit, who reviews the files, and what the buyer sees while processing is incomplete. Do not imply that a general public form is suitable for every confidential or restricted document.

Record the RFQ reference, submitting contact, received time, original filename, application file identifier, processing state, and intended staff access. Filename alone should not determine the customer or request association. Two buyers can legitimately upload different files named drawing.pdf.

Keep receipt, processing, and availability separate

An attachment can be received but not yet available for normal staff use. Agree the states and the responsible person for a rejected, incomplete, or review-required file. A successful message receipt should not imply that engineering has a usable drawing package.

OWASP's file-upload guidance recommends layered controls, including allowed file types, size limits, generated storage names, and protected storage outside the public web root where possible. It also cautions against trusting the supplied content-type header. Ask the developer which controls apply to the proposed implementation and who maintains them.

Keep handling understandable to staff. A quote coordinator should know whether a file is waiting for review or was rejected, with an agreed way to request a replacement. Do not make users repeatedly download an unresolved attachment to discover its status. Any checking or preview service must be approved for the information it receives; automatically forwarding buyer files to an unrelated public service can change the confidentiality boundary.

Use harmless, synthetic documents for the acceptance test in an authorized staging environment. The demonstration below requires no real buyer drawings or malicious files.

Test two RFQs with the same filename

Hypothetical demonstration: Customer A submits RFQ-A with a synthetic drawing.pdf containing an obvious A marker. Customer B submits RFQ-B with a different drawing.pdf containing a B marker. The approved test roles are coordinator A, assigned only to RFQ-A, coordinator B, assigned only to RFQ-B, and a visitor with no file access. These are invented records and permissions for evaluation.

1. Receive both uploads. Confirm that each is associated with its own RFQ and has a distinct stored identity despite the matching filenames.
2. After the agreed processing checks, coordinator A retrieves A's document and coordinator B retrieves B's. Confirm the document content, not just the displayed filename.
3. Using only the known synthetic test-file addresses, check that the other coordinator cannot retrieve the original through the protected application route.
4. Repeat as the visitor. A request reference or a hidden button must not grant access to the private document.
5. Generate the normal preview or thumbnail, if offered, and repeat the same role checks on that separate resource.

The pass condition covers the whole package. Protecting the PDF while leaving its drawing preview publicly readable would still reveal information. Keep an inventory of originals, previews, converted files, and exports so the developer can demonstrate the relevant controls for each.

OWASP's authorization guidance recommends denying access by default and validating permission on every request, including static resources. The RFQ assignment rules in this example are proposed business requirements, not a claim that every manufacturer needs the same account model.

Inspect notification and temporary links

Open the actual test notification sent to the designated test inbox. Does it link to a protected RFQ record, include an attachment, or contain a temporary file link? Those options have different handling consequences. Decide deliberately what recipients receive, how they are selected, and what can be forwarded.

A temporary URL is not necessarily tied to the website login. As a named-platform example, Amazon S3's presigned-URL documentation describes time-limited access granted to someone possessing the URL, which can be used more than once before expiration. This does not mean your website uses S3; it illustrates why the developer must explain the access mechanism.

If temporary links are proposed, agree their lifetime and permitted audience, then test the documented expiration and revocation behavior. Do not assume that removing a website account instantly invalidates every previously issued link. Ask what action controls future retrieval and what happens to links already placed in notifications.

Keep private document URLs out of public pages, marketing analytics fields, and routine screenshots shared outside the approved team. A website cannot retract a copy that someone has already legitimately downloaded or received by email. Choose the distribution method with that practical limit in mind.

Do not use search settings as file privacy

A developer may offer to hide an upload directory from search engines. That addresses discovery, not whether an unauthorized person can open a known address. Google's guidance on controlling shared content explains that a noindex rule can keep a page out of Search while people with its link can still visit it. Private content needs access protection.

Keep the public capability pages and useful guides discoverable while protecting the private RFQ resources separately. Blocking the entire business website is not a substitute for designing the attachment route. Test the known document address directly under the agreed roles rather than treating absence from a search result as proof of privacy.

Review access after the inquiry changes

Continue the synthetic example by reassigning RFQ-A. Check who approves the change and which active sessions or links remain usable under the documented policy. The next owner should find the required file, while a removed user should lose the access the policy says is revoked. Capture actual observations rather than assuming that changing a name on the screen updates every permission.

Agree retention and deletion responsibilities with the business owner. Include originals and generated previews in the discussion, and ask how backups, exports, and already-sent copies are handled. Do not display a message claiming everything is deleted if the system has removed only the visible RFQ link.

Where ongoing customer access is needed, use a separately scoped customer portal workflow. A visitor's ability to submit an inquiry does not automatically justify access to another request or to internal production records.

Bring a file-handling checklist to the project

• Public brochures and incoming private attachments follow separate release rules.
• Two same-named files remain associated with the correct synthetic RFQs.
• Approved roles retrieve the intended originals; other roles do not.
• Previews, exports, and notification links are included in the test.
• Processing failures have a visible owner and buyer recovery route.
• Temporary-link lifetime, reassignment, and removal behavior are demonstrated.
• Retention responsibilities and limits of already-distributed copies are documented.

These are proposed acceptance requirements, not a claim that your current site or a Ploqy product already implements them. Record results with the developer and arrange a security review appropriate to the workflow before handling real sensitive files. A clear, dependable inquiry route gives buyers a practical way to contact you; it does not guarantee traffic or orders.