Application hardening
Server-side isolation and passwordless access (covered elsewhere in this section) are only half of the picture. This page describes the defences that operate in the browser and at the upload boundary - the layers that limit what a page can do and keep hostile files away from your data.
A strict Content Security Policy
Every page Oblifee serves carries a Content Security Policy (CSP) - a browser-enforced rule that says exactly which sources a page is allowed to load scripts, styles, fonts, images and network connections from. Anything not on that short allow-list is blocked by the browser itself.
The policy is deliberately tight:
- Scripts, styles and connections default to Oblifee's own origin, with a small, explicit set of trusted providers (payment, support and telemetry) added only where a feature needs them.
- Nothing may load code from an arbitrary third party.
The practical effect is that even if malicious content were ever injected into a page, the browser would refuse to run it, because it would not come from an allowed source.
Security response headers
Alongside the CSP, every response sets headers that harden the browser's behaviour:
| Header | What it does |
|---|---|
| Content-Security-Policy | Restricts where scripts, styles, images and connections may come from |
| Strict-Transport-Security | Forces HTTPS, so traffic is always encrypted in transit |
| X-Frame-Options | Stops other sites embedding Oblifee in a frame (clickjacking defence) |
| X-Content-Type-Options | Stops the browser second-guessing a response's content type |
| Referrer-Policy | Limits how much address information is shared when you follow a link out |
Safe rendering
Oblifee renders pages with a templating system that escapes output by default: values that originate from data - a product name, a business address, a note you typed - are treated as text, not as markup, so they cannot smuggle in active content. Combined with the CSP above, this closes the common path by which user-supplied data becomes an injected script.
Uploads are quarantined and scanned
Anything you upload - an import spreadsheet, a supplier packaging spec, on-pack artwork - is treated as untrusted until proven safe. Uploads go through a quarantine step before a single byte is parsed.
The design is built around a few firm rules:
- Cheap refusals first. Files that are empty, over the size limit, or not an allowed type are rejected before anything is stored.
- Scan before parse. An uploaded file is scanned for malware in quarantine, and only a file that comes back explicitly clean is ever read.
- Fail closed. Anything other than a clean verdict - malicious, not-scanned, unreadable, or a file that has vanished - is treated as not safe and is not parsed. Uncertainty never resolves to "open it".
- No customer credential for the quarantine. Files always arrive through the app; there is no way for a customer to write directly into the quarantine store, so a scan verdict cannot be forged.
- Kept only as long as needed. Once its rows are safely imported (or it is blocked), the file itself is removed - Oblifee keeps the extracted data, not the document.
:::note Honest about scanning Where the malware-scanning service is not enabled in a given environment, uploads still work and each import is recorded honestly as not scanned rather than being silently treated as safe. :::
Layered, on purpose
No single control is trusted on its own. A hostile file has to get past pre-checks, quarantine and a scan; a hostile script has to get past output escaping and the Content Security Policy. Defence in depth means an attacker must defeat several independent layers, not one.
Where to go next
- Secrets & managed identity - how the server side avoids standing credentials.
- Data handling - what happens to the data once a clean upload is parsed.
- Bulk import - the user-facing side of uploading a spreadsheet.