Security for Insurtechs: the anatomy of an API flaw that exposes policies and health data
Digital insurance is born API-first and partner-first — and inherits an attack surface most companies discover too late. We show how Decripte finds the flaw before the attacker, contains the incident, and builds the security foundation that regulators and customers demand.
Direct answer
To protect an insurtech, start by treating the API layer as the real perimeter: enforce object-level authorization (against BOLA/IDOR), centralize secrets management for partner integrations, instrument a 24x7 SOC with claim-fraud and account-takeover detection, and subject every release to pentest and continuous vulnerability management. In parallel, structure the handling of personal, financial, and health data under the LGPD — including the legal basis for sensitive health data and the incident response plan with ANPD notification. Decripte covers this full cycle: discovery via pentest, containment within 1 hour, and building a secure SDLC.
24/7
SOC monitoring APIs and logins
<=1h
Incident containment SLA
LGPD
Health data = sensitive data
OWASP API
Top 10 as the pentest baseline
In summary
- ›Most breaches in insurtech are not in the business code, but in API authorization: an endpoint that returns another customer's policy or health report when you swap an ID (BOLA/IDOR).
- ›Health data is sensitive personal data under the LGPD and requires a specific legal basis and heightened care — a generic sign-up consent is not enough.
- ›Integrations with insurers, reinsurers, clinics, and payment providers multiply secrets (tokens, keys) that, once leaked in repositories or logs, become an entry point.
- ›Claim fraud and account takeover are business threats, not just IT threats — they require behavioral detection in the SOC, not just a firewall.
- ›Decripte closes the loop: the pentest finds the flaw, the SOC and Incident Response contain it, and Vulnerability Management plus a secure SDLC prevent recurrence.
Cibersegurança para Insurtech
Digital insurance is born API-first and partner-first — and inherits an attack surface most companies discover too late. We show how Decripte finds the flaw before the attacker, contains the incident, and builds the security foundation that regulators and customers demand.
Why insurtechs are targets: the risk surface of digital insurance
An insurtech is not a traditional insurer that digitized its processes — it is born as software. Quoting, policy issuance, premium payment, and claim filing and adjustment all happen through the app and the API. This brings product speed, but it also concentrates in a few technical layers data that, taken together, is extraordinarily sensitive: tax IDs, address, income, banking and card data, health history, medical reports, risk profile, and, in some lines of business, geolocation and telemetry.
The problem is one of maturity, not competence. Small teams, pressure to ship, and architectures that grow by accretion cause security to be treated as a backlog item. Meanwhile, the company already integrates dozens of partners — insurers, reinsurers, clinics, labs, anti-fraud providers, payment gateways, credit bureaus — and each integration is a new trust relationship, a new secret, and a new path for data to leak.
The five threats that show up most in insurtech
- ›Data leakage via API: endpoints that expose third parties' policies, health data, or payment data through an authorization flaw.
- ›Digital claim fraud: manipulation of claims, documents, and adjustment flows to receive an undue payout.
- ›Authorization flaws in apps: an ordinary user accesses functions or records that should be restricted.
- ›Compromise of partner integrations: a leaked token from an insurer or gateway turns into privileged access.
- ›Account takeover: hijacking a policyholder's account for fraud, beneficiary changes, or data extraction.
The common denominator of these five threats is the application and API layer. That is why, in insurtech, traditional perimeter security solves little: the attacker does not need to knock down the firewall — they talk to your API exactly like a legitimate customer, only asking for someone else's data.
Blind spot #1: broken API authorization (BOLA/IDOR)
The most common and most dangerous flaw in digital insurance is broken authorization at the object level, known as BOLA (Broken Object Level Authorization) in the OWASP API Security Top 10 and popularly as IDOR. The pattern is simple: the API authenticates the user correctly — it knows who is logged in — but it does not verify whether that user has rights over the object being requested.
How the flaw manifests in practice
An endpoint like /apolices/48213 returns policy number 48213. If the application trusts the ID sent by the client and does not check whether the policy belongs to the authenticated user, all it takes is to change it to 48214, 48215, and so on to sweep the entire database. When that policy carries health declaration attachments, reports, or payment data, a single poorly protected endpoint leaks sensitive data for the whole book of business.
Equally dangerous variations include function-level authorization (BFLA) — when an ordinary user calls an administrative endpoint — and excessive data exposure, in which the API returns more fields than the screen shows, and the attacker reads the raw JSON. In insurtech, that raw JSON often contains what should never leave: an incompletely masked card number, the diagnostic code of a medical condition, a beneficiary, a coverage amount.
Why pentest is the right method here
Automated scanners rarely find BOLA, because the flaw depends on business context: the scanner does not know that policy 48214 belongs to another customer. It takes a human tester modeling roles, creating two accounts, and proving that one can see the other's data. This is exactly the kind of manual, business-logic-driven testing that Decripte performs in application and API pentests.
Is insurtech data already exposed or up for sale? Find out now — for free.
Sem cartão, sem compromisso. Descubra em minutos o que já vazou da sua empresa e qual é o seu risco real.
Secrets and partner integrations: the trust that becomes an entry point
Each integrated partner requires a credential: an insurer's API key, a certificate for the payment gateway, an OAuth token for the lab, a webhook key for the anti-fraud provider. In fast-growing teams, these secrets end up where they should not — hardcoded in the code, in versioned environment variables, in committed .env files, in debug logs, in internal chat messages, and in CI pipelines.
Where secrets leak in insurtechs
- ›Git repositories: keys committed into history that persist even after being removed from the current code.
- ›Logs and observability: tokens printed in request logs that flow to third-party tools.
- ›Front-end: integration keys embedded in the mobile app or web bundle, extractable by reverse engineering.
- ›CI/CD pipelines: secrets exposed in build variables or artifacts.
- ›Documentation and Postman: collections shared with valid production tokens.
The risk compounds: a single leaked partner token can grant read or write access to systems that handle the entire book's data — and the leak does not happen in your infrastructure, which makes it harder to detect. That is why secrets management is not an operational detail; it is a first-order security control in digital insurance.
Minimum secrets management that Decripte deploys
- ✓A centralized vault (secrets manager) with identity-based access and automatic rotation.
- ✓Secret scanning in the code and Git history, with blocking at commit time (pre-commit / CI).
- ✓Least-privilege principle per integration: each token does only what the partner needs.
- ✓Immediate rotation and revocation of any exposed credential, with an audit trail.
- ✓Segregation of production and test secrets; no production tokens in shared collections.
Claim fraud and account takeover: business threats the SOC must see
Not every threat in insurtech is a classic technical exploit. Digital claim fraud uses the product's legitimate flow: tampered documents, duplicate claims, synthetic identities, collusion to trigger undue coverage. Account takeover (ATO) hijacks a real policyholder's account — via a leaked password, phishing, or SIM swap — to change banking data, the beneficiary, or to extract information.
These vectors are not detected by a firewall: they are detected by behavior. A login from an improbable geography, multiple password-reset attempts, a spike in claims from the same device, a sequence of queries to policies that do not belong to the user — all of these are signals. Decripte's 24x7 SOC correlates these application, authentication, and API signals in real time, not just network events.
Detection that matters in digital insurance
The value of the SOC for an insurtech lies in monitoring the business layer: object enumeration attempts (ID sweeping), authentication anomalies suggesting ATO, and claim-adjustment patterns that fall outside the curve. Monitoring only CPU and network traffic misses exactly what hurts most in insurance: fraud and leakage through the misuse of legitimate functions.
LGPD in digital insurance: health data is sensitive data
The LGPD (Law No. 13,709/2018) classifies health-related data as sensitive personal data. This has concrete consequences for an insurtech: processing requires an adequate legal basis — and generic sign-up consent usually is not enough for everything. The law itself provides specific bases for sensitive data, and there are relevant restrictions on the use of health data by health plans and insurers for risk selection and coverage exclusion. The practical point is: processing health data requires deliberate, documented, and auditable legal grounds, not a boilerplate clause.
LGPD obligations that weigh most in insurtech
- ›A specific legal basis and a record of processing operations (ROPA), with extra attention to health and financial data.
- ›Fulfilling data subject rights: access, correction, portability, and deletion — which requires knowing where each piece of data lives.
- ›Reporting a security incident to the ANPD and to data subjects when there is relevant risk or harm, within a reasonable timeframe.
- ›A designated Data Protection Officer (DPO) and a working data subject support channel.
- ›Technical and administrative security measures proportional to the risk — a requirement the ANPD makes explicitly.
When the product also touches card payments, PCI-DSS comes into play — the payment card industry standard that imposes controls over the storage, transmission, and processing of card data. The combination of LGPD + PCI-DSS defines much of an insurtech's compliance bar — and both are addressable with the right architecture (tokenization, data minimization, segregation), far cheaper if designed early.
Common mistake
Treating compliance as a document. An impeccable privacy policy paired with an API that leaks medical reports is not compliance — it is exposure with the appearance of governance. LGPD compliance in insurtech has to be technical before it is textual: data minimization, access control, encryption, and logging of who accessed what.
What would an incident in insurtech cost? See your real risk before it happens.
Sem cartão, sem compromisso. Descubra em minutos o que já vazou da sua empresa e qual é o seu risco real.
Secure SDLC: how to keep the flaw from returning in the next deploy
Finding and fixing an API flaw once resolves an incident. Preventing the next one from being born resolves the problem. In insurtech, where deploys happen several times a week, the only sustainable defense is to embed security into the development cycle — the secure SDLC. The idea is not to slow the team down, but to give it rails: reusable authorization patterns, automated verification, and review where it matters.
The secure SDLC that Decripte helps build
- ✓Lightweight threat modeling on features that touch sensitive data or money, before coding.
- ✓Static analysis (SAST) and dependency analysis (SCA) in the pipeline, failing the build on critical findings.
- ✓Automatic secret scanning at commit and in CI.
- ✓Authorization tests as part of the suite: each sensitive endpoint has a test proving that one user cannot access another's object.
- ✓Application and API pentesting on every relevant release, not once a year.
- ✓Continuous vulnerability management, prioritized by real exploitability and exposure, with a remediation SLA.
The gain is cultural as well as technical: the team starts treating authorization as a product requirement, the same way it treats the claim business rule. That is what separates an insurtech that fights fires from one that scales with confidence.
How Decripte operates: from pentest to rebuilding the security foundation
Decripte does not deliver a report and leave. The insurtech model is a cycle: we discover the flaw via pentest, we contain the incident with SOC and Incident Response when it happens, and we rebuild the foundation — authorization, secrets, SDLC, compliance — so the company does not depend on luck in the next deploy.
The differentiator in digital insurance
We treat the API as the real perimeter. Our pentests are business-logic-driven — we model roles, create accounts, and prove undue access to policies and health data — not driven by a scanner checklist. And we connect discovery to operations: what the pentest finds becomes a detection rule in the SOC and a prioritized item in Vulnerability Management.
For the company that does not yet know the size of its own exposure, the entry point is the free Threat Management assessment at decripte.com.br/intelligence-center, which provides an initial risk read via OSINT. From there, we structure a tailored program.
Anatomy of a real case: the API that returned any customer's policy
Real, de-identified example
Real case, anonymized (without identifying the client). A digital health-insurance insurtech, with roughly 80,000 active policyholders, offers a mobile app and a web portal. Claim adjustment is 100% digital: the policyholder submits reports and receipts through the API. Over six months of growth, the team integrated a reinsurer, two labs, and a payment gateway. Security had never gone through an independent offensive test. During a pentest contracted for due diligence on an investment round, Decripte found the problem.
Discovery (pentest)
The tester creates two policyholder accounts. When querying their own claim, they observe the endpoint /sinistros/{id}/anexos. By changing the ID to sequential values starting from account A, they receive account B's attachments — including medical reports and bank statements. BOLA/IDOR is confirmed: the API authenticates but does not authorize per object. The potential exposure reaches the entire book of business.
Escalation and containment (<=1h)
Because it is a critical finding involving health data, Decripte triggers the incident protocol. In under an hour, the vulnerable endpoint is placed behind an emergency ownership check and the anomalous traffic is blocked at the edge. The SOC begins monitoring ID enumeration attempts in real time to detect any exploitation in progress.
Investigation and scoping
Analysis of historical access logs to determine whether the flaw was exploited before discovery: sequential ID-sweeping patterns, call volume per account, and origins. The scope of potentially exposed data and the list of affected data subjects are defined, forming the basis for the notification decision.
Eradication
Definitive fix: object-level authorization applied centrally (middleware), not endpoint by endpoint. Review of all endpoints that receive a customer ID. Reduction of the API payload to return only the necessary fields (ending the excessive data exposure). Secret scanning reveals a lab token committed in Git, which is rotated.
Recovery and LGPD
With the scope defined, the communication is structured: a risk assessment for data subjects, preparation of notification to the ANPD and to policyholders per the LGPD, and a support channel. The insurtech resumes normal operation with the endpoint fixed and monitored.
Rebuild (secure SDLC)
Decripte deploys authorization tests in the automated suite, SAST and secret scanning in CI, a secrets vault with rotation, and threat modeling for sensitive features. The pentest stops being a one-off event and becomes part of the release cycle.
Lessons learned
The flaw was not in the insurance logic, but in the assumption of trusting the ID sent by the client. The fundamental fix was to change the culture: authorization becomes a product requirement and a mandatory test. The SOC gains detection rules derived from the finding.
Outcome with Decripte
What could have been a massive health-data breach — harming 80,000 data subjects, triggering compulsory ANPD notification, and losing the investment round — was contained before becoming a public incident, because the flaw was found by a pentest and not by an attacker. The insurtech came out with authorization fixed at the root, secrets management deployed, a secure SDLC running, and continuous monitoring by the 24x7 SOC. Security due diligence went from being an operational risk to being a sales argument for the investor.
Don’t wait for the incident. Start hardening insurtech today.
Comece pelo diagnóstico gratuito agora e veja em minutos o que já vazou. SOC 24x7 e contenção em até 1h nos planos pagos.
How Decripte responds to an incident at an insurtech
When an insurtech suffers a data breach, claim fraud at scale, or an integration compromise, the clock is running — and health data turns the incident into a regulatory obligation. Decripte's response is structured to contain fast and protect the company legally.
- Escalation and immediate triage: as soon as the alert arrives (from the SOC, the client, or a partner), we classify severity and determine whether sensitive personal data is involved — which raises the priority and starts the LGPD clock. Containment SLA within 1 hour.
- Containment: we isolate the vector — blocking the vulnerable endpoint at the edge, revoking compromised tokens, suspending accounts in account takeover — without taking down the entire product when possible.
- Evidence preservation: we capture logs, snapshots, and access trails forensically, to reconstruct what happened and support any legal and regulatory decisions.
- Investigation and sizing: we determine the real scope — which objects were accessed, by whom, and whether there was exfiltration — distinguishing potential exposure from actual exploitation.
- Eradication: we fix the root cause (authorization, secret, configuration), not just the symptom, and validate the fix with a new test before reopening the flow.
- Recovery and LGPD notification: we support the decision to notify the ANPD and data subjects when there is relevant risk, with the technical grounding of the scope, and we restore monitored operation.
- Partner communication: when the origin or impact involves an integrated insurer, gateway, or lab, we coordinate containment on their side as well.
- Lessons learned and hardening: we convert the incident into detection rules in the SOC and prioritized items in Vulnerability Management, closing the loop to prevent recurrence.
How Decripte structures an insurtech's security
Incident response puts out the fire; structure prevents the next one. Decripte organizes digital-insurance security into pillars that target exactly where the sector fails: API, secrets, fraud detection, and compliance.
API security and authorization
Adoption of the OWASP API Security Top 10 as a baseline, with a focus on object-level authorization (anti-BOLA/IDOR), function-level control (anti-BFLA), and data minimization in responses. Validated by manual, business-logic-driven pentesting.
Secrets and integrations management
A centralized vault with automatic rotation, secret scanning in the code and in CI, and least privilege per partner. Each insurer, lab, or gateway integration has a scoped and auditable credential.
Detection and 24x7 SOC
Monitoring of the application and authentication layer — ID enumeration, login anomalies (ATO), and claim-fraud patterns — with real-time correlation and coupled response, not just network events.
Secure SDLC and vulnerability management
Security embedded in the pipeline: SAST, SCA, secret scanning, automated authorization tests, and pentesting on every relevant release, with vulnerabilities prioritized by real exploitability and a remediation SLA.
LGPD and PCI-DSS compliance
Processing of health and financial data with the correct legal basis, ROPA, fulfillment of data subject rights, an ANPD notification plan, and technical controls proportional to the risk. When cards are involved, PCI-DSS controls designed into the architecture.
Recommended plans for Insurtech
Pentest
It is the method that actually finds BOLA/IDOR and authorization flaws in insurance APIs — manual, business-logic-driven tests that prove undue access to policies and health data, something scanners do not detect. Indispensable on every relevant release and in investment due diligence.
See plan →24x7 SOC
It monitors the business layer of digital insurance — ID enumeration, account takeover, and claim-fraud patterns — in real time, detecting the misuse of legitimate functions that the firewall does not see.
See plan →Vulnerability Management
In insurtechs that deploy continuously, it turns one-off findings into a program: prioritization by real exploitability, a remediation SLA, and integration into the SDLC to keep the same class of flaw from returning in the next release.
See plan →Compliance
Health data is sensitive under the LGPD and card-based insurance attracts PCI-DSS; technical and documentary compliance protects the company from the regulator, the data subject, and the loss of contracts due to a security due-diligence failure.
See plan →Frequently asked questions
What is the biggest security risk specific to an insurtech?
Broken API authorization (BOLA/IDOR): an endpoint that returns another customer's policy, report, or payment data when you swap an identifier. Because it concentrates personal, financial, and health data, a single poorly protected endpoint can expose the entire book of business. It is the flaw we find most often and the one that most requires manual pentesting to be detected.
Doesn't an automated vulnerability scanner solve it?
It solves part of it. Scanners find known technical flaws (vulnerable versions, bad configurations), but they rarely detect BOLA, business-logic fraud, and excessive data exposure, because these depend on context — the scanner does not know that a given policy belongs to another customer. That is why manual pentesting is irreplaceable in digital insurance, complemented by continuous vulnerability management.
Does policyholders' health data change my LGPD obligations?
Yes. Health-related data is classified as sensitive personal data by the LGPD, which requires a specific legal basis and heightened care — generic sign-up consent usually does not cover every use. There are also restrictions on using health data for risk selection. In practice, this means grounding and documenting the processing and applying stricter technical controls for access and encryption.
How do you handle the tokens and keys of our partner integrations?
We deploy secrets management: a centralized vault with automatic rotation, secret scanning in the code and Git history, blocking of credential commits, least privilege per integration, and immediate revocation of any exposed secret. It is one of the highest-impact controls in insurtech, because a leaked partner token can grant access to the entire book's data.
How quickly does Decripte contain an incident?
The Incident Response containment SLA is within 1 hour from escalation. For insurtechs, we immediately classify whether sensitive data is involved — which raises the priority and starts the LGPD regulatory clock — and we contain the vector (endpoint, token, account) while preserving evidence for the investigation and for a possible ANPD notification.
Do I need to be certified in PCI-DSS or ISO 27001 to sell digital insurance?
It depends on the product and the contracts. PCI-DSS applies to the processing of card data and is usually required by acquirers and payment partners. ISO 27001 and SOC 2 are not required by law, but they are increasingly demanded by partner insurers, reinsurers, and investors in due diligence. Decripte structures the company to meet these requirements and supports the certification journey.
How do you detect claim fraud and account takeover?
These vectors use the product's legitimate flows, so they are detected by behavior, not by a firewall. The 24x7 SOC monitors authentication anomalies (improbable logins, mass password resets), object enumeration, and claim-adjustment patterns outside the curve, correlating application and API signals in real time to trigger the response before the damage materializes.
Where do I start if I don't yet know my exposure?
With the free Threat Management assessment at decripte.com.br/intelligence-center, which provides an initial risk read via OSINT, with no commitment. From there, we structure the program — pentest, SOC, vulnerability management, and compliance — to fit. To engage directly, use decripte.io/start or reach us at /contato.
Sector terms
- BOLA / IDOR
- Broken Object Level Authorization (item #1 of the OWASP API Security Top 10), also known as IDOR. A flaw in which the API authenticates the user but does not verify whether they have rights over the requested object, allowing access to other customers' data by swapping an identifier.
- Sensitive personal data
- An LGPD category that includes health-related data, among others. It requires a specific legal basis and reinforced protection — central to health insurtechs, which handle medical reports and declarations.
- Account takeover (ATO)
- Hijacking a legitimate user's account (via a leaked password, phishing, or SIM swap) for fraud, beneficiary changes, or data extraction. In insurance, it is a vector for both fraud and data leakage.
- Secure SDLC
- Secure Software Development Lifecycle: the practice of embedding security throughout the development cycle — threat modeling, static analysis, secret scanning, and authorization tests in the pipeline — to prevent flaws from being born with each deploy.
- Secrets management
- A set of controls to store, scope, rotate, and audit credentials (tokens, keys, certificates) for integrations, preventing them from leaking in code, logs, or pipelines and becoming an entry point.
- PCI-DSS
- Payment Card Industry Data Security Standard: the payment card industry security standard that imposes controls over the storage, transmission, and processing of card data, applicable to insurtechs that process premium payments by card.
Decripte protects and responds to incidents in insurtech.
Pentest, 24x7 SOC, incident response with a 1-hour containment SLA and compliance — without building an internal team. Or start free by seeing what has already leaked from your company.