We find the real risks, explain them in plain language, and help you fix them.
Amendment 13 to Israel's Privacy Law is already in effect
The amendment has been in force since 14 August 2025, and the grace period to appoint a privacy officer ended on 31 October 2025. The Privacy Protection Authority can now impose fines itself, without going to court: up to 5% of annual turnover, capped at ₪140,000 a year for smaller businesses. In July 2026 it issued the first fine under the amendment, ₪256,000, for reporting a security incident late.
IAPP — Amendment 13 overviewPearl Cohen — first administrative fine
An external exposure assessment is a review of everything your business exposes to the open internet — domains and subdomains, email configuration, security certificates, your public site, and leaked keys — performed from the outside, with no passwords and no access to your systems, ending in a prioritised list of what to fix first.
IBM's 2025 report puts the average time just to identify a data breach at 158 days, plus another 83 days to contain it. The point of this check is that you find out first.
| Aegis | Full pentest | Self-serve scanner | |
|---|---|---|---|
| Price | ₪1,990 fixed | ₪15,000–150,000 | $9–29 / month |
| Human review of every finding | Yes | Yes | No |
| Explained in the owner's language | Yes | Usually not | No |
| Retest included | Yes | Sometimes | No |
| Active exploitation attempts | No | Yes | No |
| Time to results | 2–5 business days | Weeks | Instant |
Price ranges for full penetration tests in Israel and for self-serve scanners are taken from public market research. Source for Israeli pentest pricing: Astra
A Symbiotic Security scan of 1,072 vibe-coded apps found that 98% had at least one security flaw. In July 2025, Wiz researchers found a flaw in Base44 itself that let anyone bypass SSO and reach private apps using only the app_id visible in the URL. The same security check we run for any business covers exactly this.
Symbiotic Security — scan of 1,072 appsWiz Research — Base44
Not a buzzword list — a short explanation of each issue we check: what the real risk is, and how it gets fixed. So you know exactly what you're paying for before you pay for it.
The problem: Every old subdomain left running — a test site, a side project, a server nobody uses anymore — is an entry point nobody's watching. Attackers scan for exactly what everyone forgot.
How it's mitigated: Full mapping of every active subdomain, cross-checked against what's actually in use, flagging anything left exposed for no reason.
The problem: Without SPF, DKIM, and DMARC configured correctly, anyone can send an email that looks like it came from your domain — to customers, vendors, even employees. It's the base of most phishing attacks targeting businesses.
How it's mitigated: Checking all three records against the standard, spotting partial or incorrect configuration, and giving the exact fix without breaking mail you actually need to send.
The problem: An expired certificate or an outdated encryption setup makes the browser show visitors a warning — damaging trust — and in serious cases allows communication to be intercepted.
How it's mitigated: Checking certificate validity, supported encryption protocols, and grading against the industry standard.
The problem: An admin panel, database interface, or internal service left reachable from the internet by mistake is a direct entry point for whoever finds it — no breach required.
How it's mitigated: Identifying every exposed service, assessing its sensitivity, and recommending it be restricted to an internal network or VPN.
The problem: If the server says "yes" to any site asking for access to its data, any external site can read sensitive data directly from a logged-in user's browser.
How it's mitigated: Testing the server's response against different origins, and restricting it to an explicit list of domains that actually need access.
The problem: Without a protection token in forms, a malicious site can get a logged-in user's browser to submit an action without them knowing — changing settings, a purchase, or a deletion.
How it's mitigated: Checking every state-changing form for a protection token, and recommending one wherever it's missing.
The problem: Without headers like Strict-Transport-Security, X-Content-Type-Options, and Content-Security-Policy, the browser never gets the basic instructions to protect the user — opening the door to clickjacking and similar attacks.
How it's mitigated: A full list of missing headers, ranked by importance, with the exact configuration to add.
The problem: An old plugin or theme in WordPress is one of the most common ways small sites get breached — with known, publicly documented vulnerabilities any attacker can look up.
How it's mitigated: Identifying the core version, active plugins, and themes, cross-checked against a known vulnerability (CVE) database.
The problem: A config file, .git, .env, or dependency manifest left publicly accessible reveals internal structure — and sometimes actual passwords or keys.
How it's mitigated: Systematic scanning of known problem paths, flagging anything that shouldn't be public.
The problem: Folders like /admin, /backup, or /internal left reachable without protection invite probing — even without a direct flaw, they hand an attacker more of a map of your system.
How it's mitigated: Mapping paths with sensitive-sounding names, and flagging each one for manual review.
The problem: When user input reaches a database query unfiltered, an attacker can alter the query to extract, change, or delete data — including customer data.
How it's mitigated: Testing safely with a benign marker, no real data extraction — every finding gets human confirmation before it counts as validated.
The problem: If user input is reflected back on a page unfiltered, an attacker can inject code that runs in another victim's browser — stealing cookies or hijacking an account.
How it's mitigated: Testing with a benign marker only, identifying where output isn't escaped before being displayed.
The problem: Any library, plugin, or server running an outdated version can carry a publicly known, documented vulnerability — thousands of automated tools scan for exactly this.
How it's mitigated: Cross-checking every component and version against an up-to-date CVE database, prioritized by real-world severity.
The problem: A parameter that accepts a URL, an XML payload, or a file path without validation can let an attacker make the server reach internal resources that were never meant to be reachable from outside.
How it's mitigated: Detecting a suspicious pattern in parameters, without real exploitation, and flagging it for precise manual review.
The problem: Tools like Lovable and Replit make shipping fast — but sometimes also make it easy to leave an API key in code sent to the browser, visible to anyone who opens dev tools.
How it's mitigated: Scanning the bundle sent to the browser, identifying any key that should only ever live on a server.
The problem: With RLS off, anyone holding the public anonymous key (already present in every browser) can read — sometimes write — directly to tables that were meant to be private.
How it's mitigated: A read-only test against the already-public anonymous key: does a table that shouldn't be public return data.
The problem: This key completely bypasses every RLS rule — if it's in code sent to the browser, whoever finds it has full access to the database.
How it's mitigated: Identifying the key by its distinct structure, and flagging it as critical for immediate rotation.
The problem: Without security rules configured, a Firebase database answers any request — even with zero authentication.
How it's mitigated: A passive check: hitting the public endpoint with no token, and checking whether it returns real data.
The problem: If a chat endpoint doesn't require login, anyone can hit it directly and burn through your paid API quota — no data stolen, just a bill run up.
How it's mitigated: A single minimal call to check whether the endpoint responds with zero authentication.
The problem: A simple message like "ignore your previous instructions" can get a model to reveal the instructions it was given — sometimes business logic or information that was never meant to be public.
How it's mitigated: A single benign message checking for language typical of an internal prompt — only run with explicit authorization, since it uses real paid usage.
The problem: If the model's response is rendered on the page without escaping, and an attacker manages to get the model to include content in that response, it becomes full XSS against anyone who sees that conversation.
How it's mitigated: Static code review to find unsafe rendering of responses, plus a recommendation to sanitize HTML before display.
The problem: If an agent can write to a database or send emails without human confirmation, a successful injection can make it take a real action nobody actually intended.
How it's mitigated: Not tested directly — a successful test would already be real damage. Instead, it's raised directly in the results meeting, with a recommendation to require human confirmation before any irreversible action.
Every finding is personally reviewed by Albert Neumann, Clarvix's founder and holder of an Offensive Security Expert certificate from Ecom School (360 academic hours, 2025) — never raw scanner output.
Once you fix something, we check again to confirm it actually worked.
Nobody can guarantee absolute security, and we won't pretend to.
Clarvix