All guides · Page 5
Browse by topic, or search for a specific concept, tool or platform.
Application protection SDK integration architecture
A protection SDK becomes part of the application lifecycle, data flow and failure handling.
Read the guidePost-build application protection
Post-build protection inserts another step between compilation and the final signed artifact. Traceability, signing order and diagnostics are central evaluation areas.
Read the guideCompiler-based RASP integration
Compiler-level protection participates in code generation. Verify framework compatibility, optimization interactions and final-package coverage with separate evidence.
Read the guideProtection across native and managed code
Mobile applications often contain several code types. Map critical flows without assuming equal protection for managed code, native libraries and bridges.
Read the guideApplication protection for Flutter
Flutter combines Dart code, native plugins and platform services. Shared code must not hide distinct Android and iOS protection requirements.
Read the guideRASP for React Native applications
React Native protection extends beyond JavaScript. Native bridges, sensitive storage and server decisions define the application's real trust boundaries.
Read the guideApplication protection for Unity games
Client integrity and game-economy security are different concerns. Rewards, purchases and competitive results must not depend solely on local values.
Read the guideKotlin Multiplatform and platform-specific RASP
Kotlin Multiplatform shares business code while platform trust mechanisms remain different.
Read the guideProtection for Capacitor and Cordova applications
In applications combining web content with native functions, the bridge is a critical trust boundary.
Read the guideDesigning an application protection policy engine
A policy engine converts security signals into transaction decisions. Define its inputs, version, failure behavior and user effects explicitly.
Read the guideEvaluating RASP signals together
Signals vary in reliability and age. Preserve their source, freshness and business impact when combining them; an unexplained score is insufficient.
Read the guideBinding integrity evidence to a transaction
Evidence not tied to the correct amount, recipient and operation may be reused in another context. Bind verification to the work the server actually performs.
Read the guideRASP verification at the API gateway
An API gateway can provide a shared verification point. Define how trusted decisions reach downstream services and whether alternative routes enforce the same rules.
Read the guideRASP for offline applications
Offline decisions rely on limited evidence. Define the duration and scope of local authority and the checks required when connectivity returns.
Read the guideRotating mobile transaction keys
Key rotation involves more than generating a replacement. Plan access to old data, older-client behavior and rejection of revoked authority together.
Read the guideCaching attestation results
A cached integrity result may no longer represent the environment at transaction time.
Read the guideSecuring the RASP event channel
Reliable delivery matters as much as event generation. Design the channel around identity, integrity, replay handling and data minimization.
Read the guideFeature flags for security controls
A flag that changes enforcement is more than an interface experiment. Authorized changes, visible versions and safe rollback belong in its design.
Read the guideWhite-box cryptography and mobile protection
White-box cryptography aims to protect key use in hostile client environments. Evaluate resistance within a defined threat model rather than accepting absolute claims.
Read the guideDesigning secret delivery to mobile applications
Delivering a secret involves more than an encrypted download. Define who may use it, for what purpose, for how long and under which device context.
Read the guideBinding evidence to JSON and Protobuf requests
Evidence must remain bound to the same business data regardless of request format.
Read the guideCombining RASP with server authorization
Application evidence informs access decisions but does not establish an account's rights to every object and function. Keep those responsibilities explicit.
Read the guideRASP compatibility with third-party SDKs
Several SDKs can affect networking, lifecycle and runtime behavior inside one process. Measure compatibility through real user flows as well as successful compilation.
Read the guideSecure device registration flows
Registering a device expands an account's trust boundary. Key generation, user verification, registration binding and removal of old devices form one lifecycle.
Read the guideWhere to place RASP checks
Check placement determines which risks can be observed. Startup checks and transaction-time evaluation have different freshness and performance costs.
Read the guideRolling out application protection gradually
Enabling a new protection policy for everyone at once can amplify unknown compatibility problems. Plan measurement, stop conditions and rollback before rollout.
Read the guideUsing RASP observation mode
Observation mode helps reveal signal distributions and legitimate-user impact.
Read the guideCalibrating RASP risk thresholds
Thresholds should reflect your users and transactions. A supplier's example value may not represent normal behavior in your application.
Read the guideInvestigating RASP false positives
Blocking a legitimate user requires a dedicated investigation. Connect support records, policy versions and device context without collecting personal secrets.
Read the guideAn application protection event taxonomy
Consistent event classes help teams discuss the same conditions accurately. Detection, enforcement, service errors and uncertain outcomes require distinct records.
Read the guideSending RASP events to a SIEM
SIEM integration improves visibility without requiring unlimited duplication of raw data. Decide schema, context, access and retention together.
Read the guideA SOC runbook for application protection
A runbook defines who investigates an alert and which evidence they need. Relate mobile events to user transactions before applying broad device restrictions.
Read the guideResponding to RASP incidents
The appropriate response depends on impact. Account revocation, transaction restrictions, key rotation and user support serve different purposes.
Read the guideHigh availability for RASP verification
When verification becomes a critical dependency, continuity belongs in the security design. Failure policy matters alongside redundancy.
Read the guideRolling back RASP policies safely
Rollback should not mean disabling protection indefinitely. Record the previous version, temporary scope and reassessment conditions.
Read the guideSetting a RASP transaction latency budget
Measure protection delay through the user's completed task. Keep startup cost, network verification and critical-operation waiting distinct.
Read the guideEvaluating application protection battery use
Frequent checks can affect battery use through CPU work, networking and background activity. Test realistic usage cycles across device classes.
Read the guideRASP and application startup time
Protection can add startup work. Measure cold launch, return from background and readiness for the first sensitive operation separately.
Read the guideInvestigating ANRs and crashes after RASP integration
New ANRs or crashes are not necessarily attack signals. Examine device cohorts, threads and SDK interactions to find the cause.
Read the guideData minimization in RASP telemetry
Collect enough context to support decisions. More personal data does not automatically improve analysis; every field needs a clear purpose.
Read the guideRetention periods for RASP events
Set retention according to investigation needs and data impact. Include logs, backups and support exports in the lifecycle.
Read the guideUser support after a RASP block
Users who believe a block is mistaken need a safe support route. Investigations should not request passwords or live session credentials.
Read the guideVersioning RASP policies
Decisions cannot be explained without knowing which rule ran for which operation. Record policy versions, rollout times and rollback relationships.
Read the guideSLOs and service indicators for application protection
A security service must do more than appear available. Track verification latency, availability, false blocks and safely completed transactions together.
Read the guideExercising a RASP service outage
Test dependency failures before they happen. Exercises show how user flows and server policies behave under uncertainty.
Read the guideManaging RASP SDK upgrades
An SDK update can change detection coverage, data use and application behavior. Review release notes, final artifacts and regression results together.
Read the guideLearning from application protection incidents
Closing an incident may require more than adding a rule. Review design assumptions, monitoring gaps and support processes together.
Read the guideIntegrity of RASP test and incident evidence
Evidence is useful when its artifact identity and change history are known. Access controls, hashes and release relationships make investigations more dependable.
Read the guideApplication protection release acceptance checklist
Acceptance should verify security controls and legitimate user tasks together. Link the final signed package, support route and rollback plan to one release record.
Read the guideTotal cost of application protection ownership
License fees are only part of the investment. Device testing, integration, investigations, support and updates determine total ownership cost.
Read the guide