November 6, 2025 • 11 mins
Remote Attestation vs. RASP: Securing Mobile APIs at the Edge (Zscaler vs. Approov/Cloudflare) On this episode of Upwardly Mobile, we dive deep into the most critical architectural debate in mobile API security today: Does security enforcement belong on the client device (RASP) or off-device at the network edge (Remote Attestation)? We break down the philosophical and technical differences between the integrated Zscaler ZSDK approach, which bundles Runtime Application Self-Protection (RASP), and the specialized, edge-native partnership between Approov and Cloudflare. Discover why security experts argue that because the attacker ultimately controls the client environment, remote attestation is superior for defense against sophisticated, targeted attacks. Episode Highlights & Key Concepts The Philosophical Divide: RASP vs. Remote Attestation The core of the debate centers on where security decision logic is insulated.
Keywords: Mobile API Security, Remote Attestation, RASP, Approov, Cloudflare, Zscaler, API Integrity, Mobile App Protection, Zero Trust Architecture, Edge Security, API Abuse Prevention, Serverless Security, JWT Attestation, Mobile Bot Mitigation, Cloudflare Workers, App Attestation.
- RASP (Runtime Application Self-Protection): This approach implements security logic within the application code to detect threats locally during runtime, often used for real-time overlay fraud, app tampering, and emulator abuse detection.
- The Risk: Any locally enforced logic provides a target for advanced adversaries. Attackers can potentially reverse-engineer RASP checks and bypass local controls to execute API requests from a tampered application instance.
- Remote Attestation (Approov/Cloudflare): This specialized approach verifies that only a genuine, untampered app can access APIs, protecting backend systems from unauthorized or rogue applications.
- Superior Resilience: Approov’s architecture minimizes local enforcement, ensuring attestation decisions are made entirely in the cloud service. This insulates the enforcement logic on the backend, offering superior resilience against sophisticated, targeted attacks.
- Zero Feedback Loop: A key security advantage is that the attacker receives no feedback from the client on why the token validation failed at the edge, significantly raising the cost and complexity of a successful attack bypass.
- Enforcement Location and TCO: The Approov/Cloudflare model focuses enforcement entirely at the Cloudflare edge using serverless functions (Workers or API Shield). This is described as a zero-operations deployment model that removes the need for customer-managed infrastructure components like Zscaler’s required App Connectors. The serverless model accelerates time-to-value and minimizes maintenance overhead.
- API Key Protection: Approov provides a critical security layer by leveraging attestation guarantees to securely deliver secrets, such as API keys, just-in-time to the application only when the environment is verified as genuine and unmodified. This capability directly mitigates the risks associated with reverse engineering hard-coded keys.
- Performance and Scale: The Cloudflare/Approov integration leverages Cloudflare’s global, high-performance network. Comparative tests show Cloudflare is significantly faster than Zscaler in various Zero Trust scenarios, a crucial factor for a smooth user experience and ensuring users don't bypass security controls. Furthermore, Approov offers a commercial attestation fabric built for scale, guaranteeing no quotas or throttling on attestation traffic for high-volume apps.
- API Governance: Cloudflare API Shield enhances protection with rigorous positive security via OpenAPI schema validation at the edge. This preemptively guards against modern API security risks like Broken Object Level Authorization (BOLA) by ensuring that only traffic conforming to the documented API structure is accepted.
Keywords: Mobile API Security, Remote Attestation, RASP, Approov, Cloudflare, Zscaler, API Integrity, Mobile App Protection, Zero Trust Architecture, Edge Security, API Abuse Prevention, Serverless Security, JWT Attestation, Mobile Bot Mitigation, Cloudflare Workers, App Attestation.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Welcome back to upwardly mobile API and app security. We're
getting straight into the architectural weeds today looking at a
really key decision point that can well make or break
your mobile API security.
Speaker 2 (00:11):
Absolutely, it's something every mobile developer, whether you're on iOS, Android, Flutter, React, Native,
and definitely security architects need to grapple with. How do
you actually secure that back end when the client, the
phone in the user's hand is potentially controlled by an attacker.
Speaker 1 (00:26):
Yeah, the material we looked at sets up this clear contrast.
You've got local enforcement or ASP runtime application self protection
being a key example, versus this other approach deterministic remote
attestation and understanding this difference is well, it's critical. It
affects ongoing work performance and how resilient you really are.
Speaker 2 (00:45):
Let's unpack that core divide a bit. The problem fundamentally
is that your mobile API is often the main way
your business interacts digitally. It's a huge transaction surface. So
if an attacker can fake being your app or tamper
with it, they can hit your APIs hard sink, data scrape,
being fraud, account takeovers.
Speaker 1 (01:01):
Right, So two philosophies trying to stop that RASP Basically says,
let's build the defenses inside the app client side logic,
trying to spot things like tampering or overlays while the
app's actually running.
Speaker 2 (01:13):
Remote attestation, though, takes the completely opposite stands. It argues
the real security decision has to be kept away from
the client device. The app has to prove its genuine,
untampered running in a safe environment, and that proof the
attestation itself gets checked somewhere else off device, usually a
dedicated cloud service.
Speaker 1 (01:31):
And we see this split reflected in different industry models.
Right you have say z Scaler integrating RASP into their
bigger SSE or ZT and A platforms. The idea there
is consolidation right one place to manage identity network access, which.
Speaker 2 (01:45):
Makes a lot of sense for internal apps BD scenarios
where managing employee access is key identities paramount there. But
the sources we reviewed really pushed back on that. For
public facing B two c APIs, they argue you need
specialization for those higher risk scenarios. That's the model you
see with folks like Approve and cloud Flare focusing purely
on that deterministic integrity check, often using a WOP a
(02:08):
web application and API protection architecture right at the edge.
Speaker 1 (02:12):
Okay, wait, if ZTNA offers that convenience, that single platform,
why wouldn't architects just want that even for mobile? Why
add another piece like approve?
Speaker 2 (02:22):
Yeah? Good question. It boils down to what the specialized
sources see as a fundamental weakness in any local security control.
That's their core critique of the RSP first idea. Let's
look at why they say that.
Speaker 1 (02:35):
This is where it gets well, maybe a bit concerning
if you're relying purely on client side stuff. The argument
is basically that any security logic you put on the device, RASP,
fancy obfuscation, whatever, it's ultimately a target.
Speaker 2 (02:45):
Exactly. Think about it. The attacker controls the environment where
the app runs. They have the device, they can use
powerful tools things like FREEDA debuggers, reverse engineering tools. They
can poke around in memory see network calls hook functions.
Speaker 1 (02:59):
So they can literally watch what the RISP checks are doing.
Speaker 2 (03:02):
Precisely. They figure out Okay, this function checks for rooting
or that function checks for tampering. Once they identify those checks,
they don't necessarily need to break complex crypto. They just
need to find where the check returns true or false.
And will force it to return the good result. So
RASP or any purely local check becomes more of a
(03:24):
speed bump. It stops casual attackers maybe, but sophisticated ones
they have a clear path to bypass it.
Speaker 1 (03:29):
Ah. Okay, So the big advantage of remote attestation isn't
just that it checks integrity, but where the check happens.
The decision logic is insulated. The attacker can't mess with
the rule book because it's not on their device.
Speaker 2 (03:41):
That's the core idea. It's deterministic, meaning the outcome is
based on factors the attacker can't easily manipulate. From the
client side. The attestation service confirms the app and its
environment are legit before it even gets near your actual API.
Speaker 1 (03:55):
Okay, let's make that concrete. How does this deterministic check
work in practice? Say in that cloud Flare approof setup
you mentioned what's the.
Speaker 2 (04:03):
Flow, right, So it's designed to be pretty lightweight for
the developer. You integrate a small approved SDK into your
mobile app. Now, when your app wants to call one
of your APIs, it first quickly talks to the approved
cloud service. It asks for a special token, a short lived,
securely signed JWT a JSON web token. This token essentially
acts as proof that the app at that moment passed
(04:25):
the integrity checks, and.
Speaker 1 (04:26):
The app just includes that token in the API request
header like an authorization bear.
Speaker 2 (04:31):
Token exactly like that, it adds the approved token. And
here's the critical edge part. The validation of that token
happens entirely at the cloud Flare edge. Could be using
cloud Flare workers, maybe API shield. The point is it
happens before the request even gets close to your actual
back end servers. If the token's bad, missing, expired, invalid signature,
(04:53):
maybe the integrity check failed, cloud Flare just drops the
request right there. It never reaches your origin.
Speaker 1 (04:58):
That sounds efficient. So what's the key security benefit for
the defender the app owner in doing it that way.
Speaker 2 (05:04):
It's the lack of feedback to the attacker. This is
huge because the check and rejection happen remotely at the edge.
The attacker tampering what the app on their device gets
well basically nothing useful back. They might just see a
generic forbidden error a four H three, or maybe the
request just times out. They don't get told why it failed.
This makes it incredibly hard and expensive for them to
(05:25):
figure out how to bypass the checks. They're just shooting
in the dark, whereas with RASP the checks are right
there for them to probe and dissect.
Speaker 1 (05:32):
Right. That opacity really rams up the difficulty for attackers
makes the whole approach much more durable over time. Okay,
let's shift gears slightly. Let's talk operational complexity. Security is vital,
but teams also worry about deployment headaches, management effort, and yeah.
Speaker 2 (05:49):
This architectural difference definitely plays out in terms of it overhead.
Let's look at the z Scaler ZT and A approach.
Speaker 1 (05:56):
Again.
Speaker 2 (05:57):
While it offers that consolidated view, actually connecting it to
your back end services often means deploying and managing what
they call app connectors.
Speaker 1 (06:05):
App connectors What are those? In simple terms, they're.
Speaker 2 (06:07):
Basically software components, sometimes running on vms that you have
to set up in your own infrastructure, your data center,
your cloud, VPC. They act as a bridge between the
z scaler cloud and your private applications. Now they're necessary
for that ZT and A model to work, but they
also mean you're managing more infrastructure, patching vms, making sure
they're highly available, scaling them up, or down dealing with
(06:28):
network can figs. It adds operational friction.
Speaker 1 (06:32):
So you might get vendor consolidation, but you pick up
some infrastructure management tasks instead.
Speaker 2 (06:36):
That's the trade off. Now, contrast that with the edge
model using serverleist functions like cloud Flare workers. Because the
enforcement logic runs on the edge provider's global network, there's
essentially zero infrastructure for the security team to manage for
that piece, no VMS to patch, no OS updates, no
scaling worries for the connectors the platform handles it. It's
(06:57):
much closer to a zero operation deployment for that security layer.
Speaker 1 (07:01):
Which means less friction, faster deployment presumably. And does this
different show up in performance too. User experience matters.
Speaker 2 (07:08):
A lot for mobile, it seems to the sources we
looked at cited some pretty significant speed differences in the
broader zero trust market measurements suggesting cloud Flares platform, including
its ZT and A like services, performed notably faster than
z scaler's equivalents, things like fifty eight percent faster for
secure web gateway tasks, thirty eight percent faster for ZT
(07:28):
access globally.
Speaker 1 (07:29):
Wow, that's quite a gap.
Speaker 2 (07:30):
Yeah, And it's not just about raw speed. Network optimization
is part of the security design. For instance, the approved
attestation specifically uses cloud Flare's argo smart routing that dynamically
finds the quickest network path for that initial integrity check communication.
The goal is to make sure adding the security layer
has minimal impact on latency, keeping the app feeling responsive.
(07:54):
They mentioned could have the latency for that check, So
speed and security can go hand in hand here.
Speaker 1 (07:59):
Okay, good, Let's zoom in on specific API threads. Now,
we hear a lot about things like BOLA Broken Object
level Authorization or BFLA broken function level authorization. How does
a specialized edge approach help tackle those modern API risks?
Speaker 2 (08:14):
This is where you get into more advanced API governance
features like cloud Flares API Shield. It really encourages a
shift towards a positive security model, and it often leverages
open API scheme of validation to do.
Speaker 1 (08:25):
That positive security. Can you clarify what that means compared
to say, a traditional firewall.
Speaker 2 (08:30):
Sure, a traditional firewall often works on a negative model.
It tries to block known bad things like specific attack signatures.
Positive security flips that you define precisely what good traffic
is allowed to look like you provide your API's blueprint,
essentially using an open API schema. The API shield Enforcement
Engine EDGE then checks every incoming request against that schema.
(08:53):
Does it use the right path, correct HTTP method, valid parameters,
expected data formats. If anything in the request deviates from
that known good schema, it gets blocked instantly. Only perfectly
conforming requests get through.
Speaker 1 (09:06):
I see so for BFLA, where an attacker might change
an ID to access someone else's data, the schema would
likely catch that unexpected parameter format or value. And for
BFLA trying to call an admin function they shouldn't. The
schema wouldn't even list that path for their user role exactly.
Speaker 2 (09:21):
It enforces the intended structure and logic of the API
right at the entry point, making those kinds of authorization
bypasses much harder. It's about structural integrity. There's one more
crucial piece, especially relevant for mobile protecting secrets within the
app itself.
Speaker 1 (09:34):
Ah Yes, the classic problem of developers sometimes having to
embed API keys or other sensitive strings directly in the
app code, which is obviously risky if someone reverse engineers it.
Speaker 2 (09:46):
Right, and this is a really neat capability offered by
systems like approve. It allows you to remove those secrets
entirely from your apps compiled code. Instead, the secrets, API, keys,
configuration settings, whatever are delivered securely, just in time, only
after the app successfully passes its remote attestation check. The
app proves it's genuine and untampered, then it receives the
(10:08):
secret it needs for the next step, maybe for calling
the actual back end API. If the check fails, no
secret is delivered.
Speaker 1 (10:15):
That's clever. So it linted that whole risk of keys
being extracted from the app binary and I guess it
also means you could rotate secrets on the back end
much more easily without needing everyone to update their app immediately.
Speaker 2 (10:25):
Absolutely huge benefit for incident response and general secret hygiene.
It shifts the defensive posture quite significantly.
Speaker 1 (10:32):
Okay, So bringing this all together for you listening, maybe
you're that security architect or mobile lead. There's a clear
strategic choice emerging here.
Speaker 2 (10:40):
Yeah, the sources really frame it as a fundamental trade off.
Are you optimizing for platform consolidation above all else that
might lean towards the integrated ZTNA approach, especially for internal
apps or particularly for your critical public facing b two
C mobile APIs is the absolute priority. Superior resilience against tampering,
(11:00):
specialized API protection, better performance, and lower operational overhead for
that specific piece. If that's the priority, the specialized edge
first attestation architecture looks well, very compelling. According to these analyzes.
Speaker 1 (11:13):
It feels like the core message is especially with attackers
getting smarter, maybe using AI to help reverse engineer apps.
Any security control you leave entirely on the client device
is living on borrowed time. Insulating that critical integrity check
remotely seems like the more future proof strategy.
Speaker 2 (11:28):
You have to weigh the long term cost and risk
of dealing with sophisticated bypasses against that initial architectural decision,
that remote insulation, that lack of feedback to the attacker
that becomes incredibly valuable.
Speaker 1 (11:39):
Some important things to think about there. That's all we
have time for today on upwardly Mobile. Thanks for tuning in.
This scession was produced using human sources assisted by artificial intelligence.
Speaker 2 (11:49):
Join us again next time as we continue exploring the
ever evolving world of mobile app and API security.
Welcome back to upwardly mobile API and app security. We're
getting straight into the architectural weeds today looking at a
really key decision point that can well make or break
your mobile API security.
Speaker 2 (00:11):
Absolutely, it's something every mobile developer, whether you're on iOS, Android, Flutter, React, Native,
and definitely security architects need to grapple with. How do
you actually secure that back end when the client, the
phone in the user's hand is potentially controlled by an attacker.
Speaker 1 (00:26):
Yeah, the material we looked at sets up this clear contrast.
You've got local enforcement or ASP runtime application self protection
being a key example, versus this other approach deterministic remote
attestation and understanding this difference is well, it's critical. It
affects ongoing work performance and how resilient you really are.
Speaker 2 (00:45):
Let's unpack that core divide a bit. The problem fundamentally
is that your mobile API is often the main way
your business interacts digitally. It's a huge transaction surface. So
if an attacker can fake being your app or tamper
with it, they can hit your APIs hard sink, data scrape,
being fraud, account takeovers.
Speaker 1 (01:01):
Right, So two philosophies trying to stop that RASP Basically says,
let's build the defenses inside the app client side logic,
trying to spot things like tampering or overlays while the
app's actually running.
Speaker 2 (01:13):
Remote attestation, though, takes the completely opposite stands. It argues
the real security decision has to be kept away from
the client device. The app has to prove its genuine,
untampered running in a safe environment, and that proof the
attestation itself gets checked somewhere else off device, usually a
dedicated cloud service.
Speaker 1 (01:31):
And we see this split reflected in different industry models.
Right you have say z Scaler integrating RASP into their
bigger SSE or ZT and A platforms. The idea there
is consolidation right one place to manage identity network access, which.
Speaker 2 (01:45):
Makes a lot of sense for internal apps BD scenarios
where managing employee access is key identities paramount there. But
the sources we reviewed really pushed back on that. For
public facing B two c APIs, they argue you need
specialization for those higher risk scenarios. That's the model you
see with folks like Approve and cloud Flare focusing purely
on that deterministic integrity check, often using a WOP a
(02:08):
web application and API protection architecture right at the edge.
Speaker 1 (02:12):
Okay, wait, if ZTNA offers that convenience, that single platform,
why wouldn't architects just want that even for mobile? Why
add another piece like approve?
Speaker 2 (02:22):
Yeah? Good question. It boils down to what the specialized
sources see as a fundamental weakness in any local security control.
That's their core critique of the RSP first idea. Let's
look at why they say that.
Speaker 1 (02:35):
This is where it gets well, maybe a bit concerning
if you're relying purely on client side stuff. The argument
is basically that any security logic you put on the device, RASP,
fancy obfuscation, whatever, it's ultimately a target.
Speaker 2 (02:45):
Exactly. Think about it. The attacker controls the environment where
the app runs. They have the device, they can use
powerful tools things like FREEDA debuggers, reverse engineering tools. They
can poke around in memory see network calls hook functions.
Speaker 1 (02:59):
So they can literally watch what the RISP checks are doing.
Speaker 2 (03:02):
Precisely. They figure out Okay, this function checks for rooting
or that function checks for tampering. Once they identify those checks,
they don't necessarily need to break complex crypto. They just
need to find where the check returns true or false.
And will force it to return the good result. So
RASP or any purely local check becomes more of a
(03:24):
speed bump. It stops casual attackers maybe, but sophisticated ones
they have a clear path to bypass it.
Speaker 1 (03:29):
Ah. Okay, So the big advantage of remote attestation isn't
just that it checks integrity, but where the check happens.
The decision logic is insulated. The attacker can't mess with
the rule book because it's not on their device.
Speaker 2 (03:41):
That's the core idea. It's deterministic, meaning the outcome is
based on factors the attacker can't easily manipulate. From the
client side. The attestation service confirms the app and its
environment are legit before it even gets near your actual API.
Speaker 1 (03:55):
Okay, let's make that concrete. How does this deterministic check
work in practice? Say in that cloud Flare approof setup
you mentioned what's the.
Speaker 2 (04:03):
Flow, right, So it's designed to be pretty lightweight for
the developer. You integrate a small approved SDK into your
mobile app. Now, when your app wants to call one
of your APIs, it first quickly talks to the approved
cloud service. It asks for a special token, a short lived,
securely signed JWT a JSON web token. This token essentially
acts as proof that the app at that moment passed
(04:25):
the integrity checks, and.
Speaker 1 (04:26):
The app just includes that token in the API request
header like an authorization bear.
Speaker 2 (04:31):
Token exactly like that, it adds the approved token. And
here's the critical edge part. The validation of that token
happens entirely at the cloud Flare edge. Could be using
cloud Flare workers, maybe API shield. The point is it
happens before the request even gets close to your actual
back end servers. If the token's bad, missing, expired, invalid signature,
(04:53):
maybe the integrity check failed, cloud Flare just drops the
request right there. It never reaches your origin.
Speaker 1 (04:58):
That sounds efficient. So what's the key security benefit for
the defender the app owner in doing it that way.
Speaker 2 (05:04):
It's the lack of feedback to the attacker. This is
huge because the check and rejection happen remotely at the edge.
The attacker tampering what the app on their device gets
well basically nothing useful back. They might just see a
generic forbidden error a four H three, or maybe the
request just times out. They don't get told why it failed.
This makes it incredibly hard and expensive for them to
(05:25):
figure out how to bypass the checks. They're just shooting
in the dark, whereas with RASP the checks are right
there for them to probe and dissect.
Speaker 1 (05:32):
Right. That opacity really rams up the difficulty for attackers
makes the whole approach much more durable over time. Okay,
let's shift gears slightly. Let's talk operational complexity. Security is vital,
but teams also worry about deployment headaches, management effort, and yeah.
Speaker 2 (05:49):
This architectural difference definitely plays out in terms of it overhead.
Let's look at the z Scaler ZT and A approach.
Speaker 1 (05:56):
Again.
Speaker 2 (05:57):
While it offers that consolidated view, actually connecting it to
your back end services often means deploying and managing what
they call app connectors.
Speaker 1 (06:05):
App connectors What are those? In simple terms, they're.
Speaker 2 (06:07):
Basically software components, sometimes running on vms that you have
to set up in your own infrastructure, your data center,
your cloud, VPC. They act as a bridge between the
z scaler cloud and your private applications. Now they're necessary
for that ZT and A model to work, but they
also mean you're managing more infrastructure, patching vms, making sure
they're highly available, scaling them up, or down dealing with
(06:28):
network can figs. It adds operational friction.
Speaker 1 (06:32):
So you might get vendor consolidation, but you pick up
some infrastructure management tasks instead.
Speaker 2 (06:36):
That's the trade off. Now, contrast that with the edge
model using serverleist functions like cloud Flare workers. Because the
enforcement logic runs on the edge provider's global network, there's
essentially zero infrastructure for the security team to manage for
that piece, no VMS to patch, no OS updates, no
scaling worries for the connectors the platform handles it. It's
(06:57):
much closer to a zero operation deployment for that security layer.
Speaker 1 (07:01):
Which means less friction, faster deployment presumably. And does this
different show up in performance too. User experience matters.
Speaker 2 (07:08):
A lot for mobile, it seems to the sources we
looked at cited some pretty significant speed differences in the
broader zero trust market measurements suggesting cloud Flares platform, including
its ZT and A like services, performed notably faster than
z scaler's equivalents, things like fifty eight percent faster for
secure web gateway tasks, thirty eight percent faster for ZT
(07:28):
access globally.
Speaker 1 (07:29):
Wow, that's quite a gap.
Speaker 2 (07:30):
Yeah, And it's not just about raw speed. Network optimization
is part of the security design. For instance, the approved
attestation specifically uses cloud Flare's argo smart routing that dynamically
finds the quickest network path for that initial integrity check communication.
The goal is to make sure adding the security layer
has minimal impact on latency, keeping the app feeling responsive.
(07:54):
They mentioned could have the latency for that check, So
speed and security can go hand in hand here.
Speaker 1 (07:59):
Okay, good, Let's zoom in on specific API threads. Now,
we hear a lot about things like BOLA Broken Object
level Authorization or BFLA broken function level authorization. How does
a specialized edge approach help tackle those modern API risks?
Speaker 2 (08:14):
This is where you get into more advanced API governance
features like cloud Flares API Shield. It really encourages a
shift towards a positive security model, and it often leverages
open API scheme of validation to do.
Speaker 1 (08:25):
That positive security. Can you clarify what that means compared
to say, a traditional firewall.
Speaker 2 (08:30):
Sure, a traditional firewall often works on a negative model.
It tries to block known bad things like specific attack signatures.
Positive security flips that you define precisely what good traffic
is allowed to look like you provide your API's blueprint,
essentially using an open API schema. The API shield Enforcement
Engine EDGE then checks every incoming request against that schema.
(08:53):
Does it use the right path, correct HTTP method, valid parameters,
expected data formats. If anything in the request deviates from
that known good schema, it gets blocked instantly. Only perfectly
conforming requests get through.
Speaker 1 (09:06):
I see so for BFLA, where an attacker might change
an ID to access someone else's data, the schema would
likely catch that unexpected parameter format or value. And for
BFLA trying to call an admin function they shouldn't. The
schema wouldn't even list that path for their user role exactly.
Speaker 2 (09:21):
It enforces the intended structure and logic of the API
right at the entry point, making those kinds of authorization
bypasses much harder. It's about structural integrity. There's one more
crucial piece, especially relevant for mobile protecting secrets within the
app itself.
Speaker 1 (09:34):
Ah Yes, the classic problem of developers sometimes having to
embed API keys or other sensitive strings directly in the
app code, which is obviously risky if someone reverse engineers it.
Speaker 2 (09:46):
Right, and this is a really neat capability offered by
systems like approve. It allows you to remove those secrets
entirely from your apps compiled code. Instead, the secrets, API, keys,
configuration settings, whatever are delivered securely, just in time, only
after the app successfully passes its remote attestation check. The
app proves it's genuine and untampered, then it receives the
(10:08):
secret it needs for the next step, maybe for calling
the actual back end API. If the check fails, no
secret is delivered.
Speaker 1 (10:15):
That's clever. So it linted that whole risk of keys
being extracted from the app binary and I guess it
also means you could rotate secrets on the back end
much more easily without needing everyone to update their app immediately.
Speaker 2 (10:25):
Absolutely huge benefit for incident response and general secret hygiene.
It shifts the defensive posture quite significantly.
Speaker 1 (10:32):
Okay, So bringing this all together for you listening, maybe
you're that security architect or mobile lead. There's a clear
strategic choice emerging here.
Speaker 2 (10:40):
Yeah, the sources really frame it as a fundamental trade off.
Are you optimizing for platform consolidation above all else that
might lean towards the integrated ZTNA approach, especially for internal
apps or particularly for your critical public facing b two
C mobile APIs is the absolute priority. Superior resilience against tampering,
(11:00):
specialized API protection, better performance, and lower operational overhead for
that specific piece. If that's the priority, the specialized edge
first attestation architecture looks well, very compelling. According to these analyzes.
Speaker 1 (11:13):
It feels like the core message is especially with attackers
getting smarter, maybe using AI to help reverse engineer apps.
Any security control you leave entirely on the client device
is living on borrowed time. Insulating that critical integrity check
remotely seems like the more future proof strategy.
Speaker 2 (11:28):
You have to weigh the long term cost and risk
of dealing with sophisticated bypasses against that initial architectural decision,
that remote insulation, that lack of feedback to the attacker
that becomes incredibly valuable.
Speaker 1 (11:39):
Some important things to think about there. That's all we
have time for today on upwardly Mobile. Thanks for tuning in.
This scession was produced using human sources assisted by artificial intelligence.
Speaker 2 (11:49):
Join us again next time as we continue exploring the
ever evolving world of mobile app and API security.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Las Culturistas with Matt Rogers and Bowen Yang
Ding dong! Join your culture consultants, Matt Rogers and Bowen Yang, on an unforgettable journey into the beating heart of CULTURE. Alongside sizzling special guests, they GET INTO the hottest pop-culture moments of the day and the formative cultural experiences that turned them into Culturistas. Produced by the Big Money Players Network and iHeartRadio.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com