Nothing was breached, nothing leaked, and no incident forced our hand — which is exactly why we're publishing this swioz security update now, while everything is calm enough to explain properly. This release doesn't add a feature you can click. It hardens everything you already click, and it puts our security posture in writing so you can hold us to it.
That's the honest framing: some of what follows shipped quietly at launch, and this update tightens, completes, and documents the whole stack. So, is Swioz safe? Our answer: safer than the market average — and, as of today, documented in writing, which most of this market can't say. A security posture you have to guess at isn't a posture — it's a vibe. Here's the actual list.
The Threat Model
We protect three things, in this order:
- Your Swioz account — the email, the password, and the session that keeps you signed in.
- The boundary around public data — Swioz must never become a tool that reaches past public surfaces, both because it's wrong and because "anonymous viewer" infrastructure drifting toward abuse is how tools like this get everyone blocked.
- Service availability — abuse, credential stuffing, and bulk scraping degrade the product for the humans who actually use it.
Everything in this update maps to one of those three.
Rate Limiting, In Both Directions
Lookups and auth endpoints now run per-IP and per-account rate limits.
The reasoning is asymmetric, and we'll be plain about it. For a human workflow — even a heavy research session with dozens of lookups — the limits are effectively invisible. For a script enumerating thousands of usernames or hammering the login form, the limits bite fast. That's not an accident of tuning; it's the design goal. A lookup tool with no governor is an abuse machine, and abuse machines either get their sources throttled into oblivion or get repurposed for things we don't want to be. We'd rather be a reliable tool for reasonable use than a fast tool for everything.
How We Handle Passwords
Your Swioz password is hashed with scrypt — a memory-hard function chosen precisely because it's expensive to attack at scale. What that means in practice:
- We store a salted scrypt hash, never the password itself.
- Nobody at Swioz — including us — can read your password. We can only verify it when you sign in.
- A database dump, in the worst case, yields slow, expensive-to-crack hashes rather than a login list.
And one adjacent fact worth its own paragraph: we never ask for your Instagram password, in any tool, for any reason. There is no feature on this site that requires it. If you ever see an Instagram login form on something claiming to be Swioz, it isn't us — leave.
Sessions That Don't Leak
Session handling got the unglamorous but decisive fixes:
- HTTP-only cookies. Your session cookie is invisible to JavaScript, which means a script injection on any third-party resource can't exfiltrate it. This is the single cheapest defense against session theft, and it's non-negotiable.
- Server-side expiry. Signing out kills the session on the server, not just the cookie in your browser. A stolen cookie dies with the session.
Cloudflare Turnstile on the Auth Flow
Signup and signin are protected by Cloudflare Turnstile — a human-verification challenge that runs without the puzzle-solving circus of older CAPTCHAs.
Why it's there: the two most common attacks against a site like ours are credential stuffing (replaying leaked email/password pairs against our signin form, hoping you reused a password) and bot signups (mass account creation for abuse). Turnstile blunts both at the door. We chose it over heavier alternatives deliberately: it's the least intrusive verification that actually works, which fits a product whose entire premise is "do less to the user."
Abuse Monitoring
Beyond static limits, we now watch traffic patterns: bulk username enumeration, scripted lookup bursts, and the specific shapes of automated abuse. The response ladder is throttle → challenge → suspend, applied in that order, because the goal is to make abuse impractical rather than to punish the ambivalent.
Two commitments that matter more than the mechanics: monitoring looks at traffic shape, not at your research content — we're not reading your lookup history to police what you're curious about. And your history remains yours: one-click clear, as shipped in the dashboard update, and no handovers of lookup data as a business practice.
What We Store — In Plain Terms
The whole inventory, in one table — this is, exhaustively, what data we store:
| Data | Stored? | Notes |
|---|---|---|
| Email address | Yes | Your account identifier |
| Password | Yes — scrypt hash | Salted, memory-hard, unreadable even by us |
| Session cookie | Yes | HTTP-only, server-side expiry |
| Lookup history (signed in) | Yes | Profile snapshots + timestamps; one-click clear |
| Anonymous lookup details | Traffic metadata only | Never linked to an identity |
| Instagram credentials | Never | We never ask for them, so we never have them |
If a site in this category can't produce a table like that — or answers "what do you store?" with marketing language — treat the silence as information. We wrote a full audit framework for exactly this question in is using an Instagram profile viewer safe?, including the five-minute checklist we'd want anyone to run on us.
The Scam Warning We Repeat On Purpose
Anonymous viewer safety comes down to two questions: what does the tool ask for, and what does it store? The single most dangerous pattern in this market fails the first question — the credential-harvesting "viewer": a slick page, a plausible loading bar, and an Instagram login form that shouldn't exist. No anonymous viewer, checker, or downloader needs your Instagram credentials. Every one that asks for them is collecting them — and the account being taken is usually followed by the contacts being scammed from it.
While we're on your safety rather than ours: if anonymous viewing tools are on your radar, your own account's hardening should be too. Our Instagram privacy settings walkthrough covers every toggle that decides what strangers, wrapper sites, and future data leaks can see about you.
What's Next
Security work never appears on a roadmap as a line item that gets checked off; it compounds. Next up: the story viewer beta hardening (reliability under ephemeral, time-sensitive content), and a public incident-reporting habit for anything that ever does go wrong — because the day you most want a vendor to be honest is the day something breaks.
Your next step: create a free account and look at what we ask for — an email, a password, nothing else. Then run the five-minute audit from the safety guide on us. We built Swioz to be the tool in this market that survives being examined; the launch announcement is where we first said so out loud, and everything since has been us keeping that promise in code.