We have third party site which creates a Web-to-case and we wanted to attach the image files to the case. The site is open to all in internet. So how to attach the image file securely in salesforce.
#Salesforce Developer #Trailhead Challenges #TrailblazerCommunity #Service Cloud
Standard Web-to-Case can’t carry attachments. The form it generates posts plain form fields, not multipart uploads, and it never creates ContentVersion records. The one answer on that thread says the same. Since your site is open to the internet, the safe approach is to keep the file upload off the Salesforce side of the public boundary until the file has been vetted.
Recommended pattern: your site’s backend handles the upload and calls Salesforce with an authenticated integration user
- Browser → your backend. The site’s own server receives the image. It validates the file before anything reaches Salesforce:
- Allow-list of types, checked by magic bytes and not just the extension (JPEG/PNG/WebP/GIF, and no SVG, since SVG can carry script).
- Hard size limit and a limit on the number of files per case.
- Malware scan (ClamAV or a cloud scanning service).
- Bot protection and rate limiting (reCAPTCHA/Turnstile, per-IP throttling).
- Backend → Salesforce, authenticated. Don’t use Web-to-Case for this flow. Create the Case through the REST API, using an OAuth Connected App / External Client App (client-credentials or JWT bearer flow) as a dedicated integration user.
- The credentials stay on your server and are never exposed in the browser.
- Give the integration user a minimal permission set: create Case, create ContentVersion, and nothing else.
- Attach the file via REST: POST a ContentVersion (base64 body for small files, multipart for larger ones), then a ContentDocumentLink to the Case. Or use the Composite API to create the Case and attach the file in one call.
- Case ID handling. Never let the browser pass a Case ID that it supplies. The backend should use the ID returned from its own Case creation.
Alternatives:
An Experience Cloud site with a Case form and the file upload component fits if the site can be replaced or embedded. It’s native to Salesforce, but the Guest User risk is real, so prefer authenticated external users over Guest access.
An Apex REST endpoint (@RestResource) fits if you need custom validation inside Salesforce. The caller still has to be authenticated, so don’t expose the endpoint to the Guest profile.
Uploading to S3 or Azure Blob and storing a link on the Case fits high-volume or large-file scenarios. The files then live outside Salesforce, so access control and retention become your responsibility.
Email-to-Case works if users can email their attachments, but sender verification is weak and attachment limits apply.
The backend-plus-REST-API approach remains the strongest option on security, but it needs developer work on the third-party site.
Avoid
- Exposing an Apex REST endpoint or Visualforce page to the Guest User profile to accept uploads. Guest access is the most common source of Salesforce data exposure, and an open file-upload path invites abuse and storage exhaustion.
- Storing credentials in client-side JavaScript.
- Trusting the filename or content type sent by the client.
Other points
- Files in Salesforce count against your file storage limits, so size caps matter.
- Decide whether the images need to be visible to the customer later, since that changes the sharing setup (ContentDocumentLink visibility).
- Consider async scanning: store the file in a quarantine state until the scan passes, then attach it.
I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.
- Browser → your backend. The site’s own server receives the image. It validates the file before anything reaches Salesforce: