Security
How ISN Free WiFi protects tenant and guest data across the Platform. Last updated 31 August 2026.
Protecting you on public WiFi
Public WiFi has a well-earned reputation for risk, and the captive portal, the one page almost everyone has to pass through to get online, is often the softest target on the whole network. Here's specifically what we defend against on that page, and how:
| Attack | How it's defended against |
|---|---|
| Session/token theft over open WiFi | Session cookies are HttpOnly (invisible to page scripts), cryptographically signed, marked Secure whenever the connection is HTTPS, and either short-lived or single-use, so a copied token stops being useful fast. |
| Fake or insecure splash pages harvesting personal details | The connect page is served over enforced HTTPS/TLS with HTTP Strict Transport Security, so anything typed there, a phone number, email, or card number, can't be read in transit. Plenty of venue WiFi splash pages are still plain HTTP; this one isn't. |
| Card skimming through a fake or compromised payment box | Card payments go straight to our payment processor's own secure hosted checkout. The card number is never seen by, or stored on, our own servers, so even a compromised captive portal couldn't expose it. |
| Device/MAC spoofing, stealing another guest's already-approved session | Returning-device recognition is rate-limited per router and MAC address, so a spoofed MAC can't be milked for repeated instant access the way a real returning guest's can. |
| "Evil twin" attacks — a fake access point broadcasting the same network name to intercept guests | Every router periodically scans nearby WiFi and alerts the operator automatically the moment a different device is heard broadcasting its exact network name. This detects and alerts — no WiFi platform can reach out and silence another device's radio — but it closes the much more common failure: most evil-twin attacks succeed simply because nobody notices one is happening. |
| Credential stuffing / automated login attempts | Rate limiting on login, signup, and password-reset forms blunts scripted brute-force attempts against an account. |
| Cross-site request forgery (tricking a logged-in browser into an unintended action) | Guest session cookies use SameSite=Strict, and the tenant dashboard's own API requires an explicit session token in a request header rather than an ambient cookie, so a forged cross-site request can't carry either. |
| Clickjacking (framing the portal invisibly to hijack clicks) | X-Frame-Options and a Content-Security-Policy block the portal from being embedded in another site's frame. |
| One venue's breach exposing another venue's guests | Every tenant's data is isolated from every other tenant's at the database level, not just checked in application code. |
Honestly stated: this protects the connection between a guest and ISN Free WiFi's own systems. Like any WiFi network, the venue's own wireless security (WPA2/WPA3, physical access to the network) is still the first line of defense, and we'd always recommend avoiding sensitive logins on any network, WiFi included, that isn't visibly using HTTPS.
Tenant data isolation
Every tenant's data — guest records, portal configuration, billing, analytics — is stored with row-level security policies enforced at the database itself, not just checked in application code. Each tenant's data is logically isolated from every other tenant and is not reachable by another tenant through the dashboard or API, regardless of which captive portal a request comes through.
Encryption
| Area | How it's protected |
|---|---|
| Data in transit | HTTPS/TLS enforced across the Platform, including HTTP Strict Transport Security so a browser never falls back to an unencrypted connection once it's visited. |
| Passwords | Hashed, never stored in plain text. Business Account and guest passwords alike are irreversibly hashed before they ever touch a database row. |
| Stored credentials | Any third-party credential a tenant supplies (a payment gateway secret key, their own outgoing email password) is encrypted at rest with AES-256-GCM before storage, decrypted only in-memory at the moment it's actually used. |
| Card payment details | Never touch our own servers. Card payments are processed directly through our payment processor's own hosted checkout — we only ever see a transaction result, not the card number itself. |
Access control & support access
ISN Free WiFi staff never ask a tenant for their dashboard password — not by phone, not by email, not in support chat. When a tenant asks us for hands-on help (for example, configuring a router), our staff access that dashboard through a separate, audited internal support mechanism tied to the staff member's own ISN Free WiFi account, never the tenant's. Every such access is logged distinctly from a tenant's own ordinary logins, so it's always clear after the fact who accessed what, and why.
Actions performed through router management and remote CLI tools are recorded in an audit log tied to the account and IP address that performed them — configuration changes on a tenant's router are always traceable back to a specific actor and moment, not anonymous.
Application security practices
- Rate limiting on public and sensitive endpoints — login, signup, password reset, and every form reachable without an account — to blunt automated abuse and credential-stuffing attempts.
- Session and one-time-use tokens (password resets, device sign-in links, team invites) are cryptographically signed and either short-lived or single-use, never a guessable sequence.
- Incoming webhooks from our payment processor are verified against a cryptographic signature before anything in a request is trusted or acted on.
- User-supplied content is escaped before being placed into emails or rendered pages, to guard against injection.
Independent internal security review — 31 August 2026
We ran a full internal security review across the Platform on 31 August 2026, covering authentication and session handling, every guest-facing endpoint reachable without an account, payment and webhook processing, and the integrations that connect to tenants' own network equipment. We're publishing what came of it rather than staying quiet about it, because a platform that only talks about security in the abstract is worth less than one that shows its work.
| Area reviewed | Outcome |
|---|---|
| Guest account data access | Found and closed a gap where a guest's own usage and account data could be requested without the request being tied to that guest's own verified session. Every affected endpoint now checks the request against the caller's own session before returning anything. |
| Network-equipment integrations | Added validation so the Platform can never be directed at an internal or private network address when connecting out to a tenant's own router-controller integration, closing a class of issue known as server-side request forgery. |
| Cryptographic comparisons | Upgraded a handful of internal security checks to constant-time comparison, removing a theoretical timing side-channel. |
| System-command handling | Removed a command-injection-shaped code path in an internal diagnostic routine. |
| Payment webhook processing | Re-verified signature checking, amount verification, and replay protection across every payment gateway we support, including the ones added most recently. All confirmed correct. |
| Authentication, OTP/2FA, password reset, session logout | Re-verified independently. All confirmed correct, no issues found. |
| Multi-captive session handling | While completing the browser-storage hardening below, found and fixed a bug where switching between captives on the same login, or ending a support "view as" session, could leave the browser using session data for the wrong captive after the page reloaded. Confirmed fixed — the browser now always ends up with exactly the session it was just issued, verified across repeated switches in both directions. |
One item came out of this review as a deliberate, scoped follow-up rather than an emergency fix: how tenant dashboard sessions are kept in the browser has now been hardened further as a defense-in-depth improvement. This wasn't a response to any confirmed issue — it was a case of moving to a stronger pattern because it was available, not because the previous one had been shown to fail.
This kind of review isn't a one-time event for us — it's something we intend to keep doing as the Platform grows.
Availability
We publish live uptime and incident information on our status page, and document what tenants can expect from us in our Service Level Agreement.
Sub-processors
We use a small set of specialist providers to run the Platform — database hosting, application hosting, SMS and email delivery, and payment processing. What each category is used for is listed in Section 6 of our Privacy Policy.
Compliance & certifications
We operate with POPIA (South Africa's Protection of Personal Information Act) in mind across the Platform, as described in our Privacy Policy. In the interest of being straightforward rather than overselling: ISN Free WiFi does not currently hold a formal third-party security certification such as SOC 2 or ISO 27001. If a specific certification matters for your organization's own procurement requirements, contact us and we'll let you know honestly where things stand.
Reporting a security issue
If you believe you've found a security vulnerability in the Platform, please report it to info@isnfreewifi.co.za with enough detail to reproduce it. We ask that you give us a reasonable opportunity to investigate and address a report before disclosing it publicly, and that you avoid accessing, modifying, or deleting data that isn't your own while testing. We don't currently run a paid bug bounty program, but we take every genuine report seriously and will acknowledge it.