Offerwall SDK Security: Best Practices for Publishers (2026)

Offerwalls are a powerful monetization tool, but they are also a magnet for fraud. Every virtual currency you award has real-world value, and sophisticated attackers will probe every weakness in your integration to extract that value without completing legitimate offers. Security is not a feature you bolt on after launch — it is a foundational design decision that affects every layer of your integration.

This guide walks through the full security stack for offerwall publishers: from server-side validation principles to device fingerprinting, proxy mitigation, and behavioral anomaly detection. By the end, you will have a concrete checklist and the technical knowledge to implement it.

1. Why Offerwall Security Matters

The economics are simple. When a user completes an offer, an advertiser pays the offerwall network, the network pays you, and you pay the user in virtual currency. If an attacker can trigger a postback without completing an offer, they get free currency. If they can trigger it a thousand times, they drain your economy. If they can do it across many accounts, they can cash out through any real-money trading pipeline your game supports.

The damage extends beyond direct financial loss:

• Economy inflation: Flooded currency devalues the in-game economy for legitimate players. See our guide on economy balance and prevention.
• Advertiser quality degradation: If fraud drives up your completion numbers with fake conversions, advertisers see poor downstream retention and lower their bids — or pull their offers entirely.
• Account-level abuse: A compromised reward pipeline can be used to fund account-selling operations, creating secondary fraud markets.
• Platform compliance risk: App stores have policies against fraudulent currency distribution. Persistent fraud can lead to app suspension.

If you are new to offerwalls, start with our introductory guide to what an offerwall is, then come back here.

2. Server-Side vs Client-Side Validation

The most important security principle in offerwall integration is this: never trust the client. The client app runs on a device controlled by the user. It can be decompiled, modified, man-in-the-middled, or entirely replaced with a script that mimics the SDK’s network calls.

What Client-Side Validation Looks Like (Wrong)

// DON'T DO THIS — client-side reward crediting
override fun onOfferComplete(userId: String, amount: Int) {
    // Attacker can call this directly via reflection
    // or by modifying the APK
    userBalance += amount
    saveBalance()
}

An attacker can decompile your APK, find the onOfferComplete callback, and call it directly — awarding themselves arbitrary currency without ever opening an offer.

What Server-Side Validation Looks Like (Right)

// Client receives a callback — but does NOT credit directly.
// Instead, it pings your server, which waits for the postback.
override fun onOfferComplete(transactionId: String, amount: Int) {
    // Notify server that a completion was reported client-side.
    // Server will only credit when the S2S postback arrives and validates.
    apiClient.notifyPendingReward(transactionId, amount)
}

// Server-side: only credit after postback signature verification
// See the postback handler in our complete postback guide

The reward is credited only when your server receives and validates a signed postback from the offerwall platform. The client callback is informational only — it can update the UI to show “reward pending,” but it never touches the balance directly.

For the full postback implementation, see our complete postback guide.

3. Postback Signature Verification (HMAC, MD5, SHA256)

Signature verification is the cryptographic proof that a postback originated from Perkox and was not tampered with in transit. Without it, anyone who discovers your postback URL can craft fake completion notifications.

How It Works

1. Perkox concatenates the postback parameters in a defined order (e.g., user_id + offer_id + transaction_id + amount + timestamp).
2. It computes a hash of that string using your secret key.
3. The hash is sent as the signature parameter.
4. Your server reconstructs the same string, computes the same hash, and compares it to the received signature using a constant-time comparison.

HMAC-SHA256 (Recommended)

// Node.js
const crypto = require('crypto');

function verifySignature(params, secret) {
    const base = `${params.user_id}${params.offer_id}${params.transaction_id}${params.amount}${params.timestamp}`;
    const expected = crypto.createHmac('sha256', secret).update(base).digest('hex');

    // Constant-time comparison — prevents timing attacks
    const a = Buffer.from(expected, 'hex');
    const b = Buffer.from(params.signature, 'hex');
    if (a.length !== b.length) return false;
    return crypto.timingSafeEqual(a, b);
}

HMAC-MD5 (Legacy — Avoid for New Integrations)

// PHP — legacy MD5 mode (do not use for new integrations)
$base = $user_id . $offer_id . $transaction_id . $amount . $timestamp;
$expected = md5($base . $secret);
// Still use hash_equals() for comparison

MD5 is deprecated for cryptographic purposes due to known collision vulnerabilities. It is supported for backward compatibility only. If your current integration uses MD5, plan a migration to SHA256 during your next release cycle.

Key Management

• Store the secret key in a secrets manager (AWS Secrets Manager, HashiCorp Vault, or at minimum an environment variable — never in source code).
• Rotate keys periodically. Perkox supports key rotation with a grace period where both old and new keys are accepted.
• Use different keys per environment (staging vs production).
• If a key is compromised, rotate immediately in the dashboard and deploy the new key to your servers.

4. Device Fingerprinting and Emulator Detection

Not all fraud comes from crafted postbacks. A significant portion comes from emulator farms — racks of virtual devices running automated scripts that complete offers at scale, collect rewards, and cash out. Device fingerprinting and emulator detection are your countermeasures.

Device Fingerprinting

A device fingerprint is a composite identifier built from hardware and software attributes:

• Hardware model, manufacturer, and build fingerprint
• Screen resolution, density, and refresh rate
• Installed sensor list (accelerometer, gyroscope, magnetometer)
• System language, timezone, and locale
• Storage capacity and available memory
• Boot time and kernel version

The fingerprint is sent to your server during SDK initialization. The Perkox platform cross-references fingerprints against known-fraud databases and flags devices that appear across an unusual number of accounts or geographies.

Emulator Detection Signals

No single signal is conclusive — legitimate users sometimes root their devices or use x86 tablets. Perkox combines multiple signals into a risk score. High-risk devices receive additional scrutiny: offers may be filtered, rewards may be held for manual review, or the device may be blocked entirely.

Root and Tamper Detection

The Perkox SDK includes root detection and integrity checks. If the SDK detects that the app’s APK has been modified (checksum mismatch) or that the device is rooted, it can:

• Report the risk level to the server alongside the device fingerprint
• Reduce the offer inventory shown to the user
• Require additional verification steps before crediting
• Refuse to initialize entirely (configurable)

For integration details, see the complete Android SDK guide.

5. Duplicate Transaction Prevention

Duplicate prevention has two dimensions: accidental (postback retries) and malicious (replay attacks). Both are solved with the same idempotency infrastructure.

Accidental Duplicates (Retries)

As covered in the postback guide, the platform retries failed postbacks. Without idempotency, a retried postback double-credits the user. The fix is a UNIQUE constraint on transaction_id in your postback log table.

-- PostgreSQL
CREATE TABLE postback_log (
    id            SERIAL PRIMARY KEY,
    transaction_id VARCHAR(128) UNIQUE NOT NULL,
    user_id       VARCHAR(128) NOT NULL,
    offer_id      VARCHAR(128) NOT NULL,
    amount        INTEGER NOT NULL,
    signature     VARCHAR(256) NOT NULL,
    created_at    TIMESTAMP DEFAULT NOW()
);

-- MySQL
CREATE TABLE postback_log (
    id INT AUTO_INCREMENT PRIMARY KEY,
    transaction_id VARCHAR(128) UNIQUE NOT NULL,
    user_id VARCHAR(128) NOT NULL,
    offer_id VARCHAR(128) NOT NULL,
    amount INT NOT NULL,
    signature VARCHAR(256) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Malicious Replays

An attacker who intercepts a valid postback (e.g., via a proxy on an unsecured network) can replay it later. If your only protection is the signature, the replay succeeds — the signature is still valid. Two additional defenses:

1. Timestamp freshness check: Reject postbacks where |server_time - timestamp| > 300 seconds. This window must be generous enough to accommodate network latency but tight enough to prevent meaningful replays.
2. Nonce tracking: For maximum security, store a nonce from each processed postback and reject any future request with the same nonce. This is stronger than timestamp-only but requires more storage.

// Timestamp freshness + idempotency combined
const age = Math.abs(Date.now() / 1000 - parseInt(params.timestamp, 10));
if (age > 300) {
    return res.status(408).send('STALE_TIMESTAMP');
}

// Then proceed to idempotency check (INSERT ... ON CONFLICT DO NOTHING)

6. Proxy and VPN Mitigation

Proxy and VPN usage is a double-edged sword. Legitimate users use VPNs for privacy. Fraudsters use proxies and VPNs to spoof geographies — completing offers targeted at high-payout countries from low-cost regions. The Perkox platform handles this at the network level, but publishers should understand the approach.

Detection Layers

• IP reputation databases: Perkox cross-references connecting IPs against commercial and open-source proxy/VPN detection databases (e.g., MaxMind, IP2Proxy). Known datacenter IPs, Tor exit nodes, and commercial VPN endpoints are flagged.
• ASN analysis: Traffic from hosting providers (AWS, DigitalOcean, OVH, Hetzner) is flagged — real users typically connect via ISP ASNs, not datacenter ASNs.
• Geo-consistency: If the SDK reports a device timezone/locale that doesn’t match the IP’s geolocation, the discrepancy is flagged. A device claiming to be in Tokyo but connecting from a Frankfurt VPN endpoint is suspicious.
• Velocity checks: If a single IP or IP range generates an unusual number of completions within a time window, it is rate-limited or blocked.

Publisher Actions

You do not need to build proxy detection yourself — Perkox handles it. But you should:

• Review the fraud signals dashboard regularly for spikes in proxy/VPN traffic.
• Configure your postback endpoint to log the source IP of each postback (for forensic analysis).
• Consider geo-restricting offers in the dashboard if you observe sustained abuse from specific regions.

For more on the signals Perkox tracks, see our fraud signals guide for publishers.

7. Behavior Intelligence and Anomaly Detection

Device fingerprinting and proxy detection catch known patterns. Behavior intelligence catches novel fraud by analyzing how users interact with the offerwall over time. Perkox’s behavior intelligence engine runs server-side and evaluates signals including:

• Completion velocity: A user who completes 20 offers in 10 minutes is likely using automation. Normal users complete 0–3 offers per session.
• Offer selection pattern: Fraudsters typically target the highest-payout offers first. Legitimate users browse by interest, resulting in a more diverse selection pattern.
• Session duration: If an offer requires a 5-minute gameplay session but the completion arrives in 30 seconds, the completion is flagged.
• Multi-account linkage: If multiple accounts share a device fingerprint, IP, or installation ID, they are clustered. One account’s fraud flag propagates to the cluster.
• Time-of-day patterns: Fraud farms often run 24/7. Legitimate users have diurnal patterns — active during daytime in their timezone, quiet at night.

What Happens to Flagged Accounts

When behavior intelligence flags a transaction, the platform can:

1. Hold the reward for manual review — the postback is delayed until a human or automated secondary review approves it.
2. Reduce the reward — in cases of minor suspiciousness, the offer may be credited at a reduced rate.
3. Block the transaction — no postback is sent, no reward is credited.
4. Shadow-ban the device — the offerwall continues to load, but offers are filtered and no completions are credited, preventing the fraudster from knowing they’ve been caught.

As a publisher, you see the outcomes in your dashboard’s fraud metrics. You do not need to implement behavior intelligence yourself — but you should configure your notification preferences so you are alerted when fraud rates spike.

8. IP Whitelisting for Postbacks

IP whitelisting is a network-level defense that restricts your postback endpoint to only accept requests from known Perkox server IPs. It is simple, effective, and should be one of the first things you configure.

Nginx Configuration

# /etc/nginx/conf.d/perkox-postback.conf

location /postback {
    # Perkox postback delivery IPs (verify current list in docs)
    allow 203.0.113.10;
    allow 203.0.113.11;
    allow 203.0.113.12;
    allow 203.0.113.13;
    allow 203.0.113.14;
    deny all;

    proxy_pass http://127.0.0.1:3000;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Cloud Firewall / Security Group

If you run on AWS, GCP, or Azure, configure your security group or firewall rules to allow inbound HTTPS only from Perkox IPs on the port your postback endpoint listens on. This is even better than application-level whitelisting because the traffic never reaches your app server.

Apache Configuration

<Location /postback>
    Require ip 203.0.113.10 203.0.113.11 203.0.113.12 203.0.113.13 203.0.113.14
</Location>

Important Notes

• Always retrieve the current IP list from the Perkox documentation. IPs may change as the platform scales.
• IP whitelisting is a first line of defense, not a replacement for signature verification. Always implement both.
• If you use a CDN (Cloudflare, Fastly), ensure it forwards the original client IP to your origin server so your whitelist checks the real source, not the CDN edge.
• Set up monitoring to alert you if postback traffic arrives from non-whitelisted IPs — this may indicate a configuration error or a spoofing attempt.

9. Security Checklist for Publishers

Use this checklist to audit your integration. Every item should be checked before launch and reviewed quarterly.

Postback Security

• ✅ Postback endpoint is HTTPS-only with a valid certificate
• ✅ Signature verification implemented (HMAC-SHA256 preferred)
• ✅ Signature comparison uses constant-time function (not ==)
• ✅ Secret key stored in environment variable or secrets manager (not source code)
• ✅ IP whitelisting configured at firewall or reverse proxy level
• ✅ Timestamp freshness check (reject postbacks older than 5 minutes)
• ✅ Idempotency: UNIQUE constraint on transaction_id
• ✅ Correct HTTP status codes returned (200 for success, 5xx for transient errors)

SDK Security

• ✅ SDK initialized with server-generated user ID (not client-generated)
• ✅ Reward crediting happens server-side only (client callback is informational)
• ✅ Root and tamper detection enabled in SDK configuration
• ✅ Device fingerprint collection enabled
• ✅ SDK version is current (update within 30 days of new releases)

Operational Security

• ✅ Postback logs retained for at least 90 days
• ✅ Alerting configured for: signature failures, 5xx error rate, duplicate rate, latency
• ✅ Dashboard fraud metrics reviewed weekly
• ✅ Key rotation process documented and tested
• ✅ Incident response plan for key compromise defined

Economy Protection

• ✅ Per-user daily reward cap configured
• ✅ Per-device completion velocity limits set
• ✅ Reward hold period for high-value completions configured
• ✅ Economy balance monitoring in place (see economy balance guide)

10. FAQ

Is client-side reward crediting ever acceptable?

No. Client-side crediting is exploitable by anyone who can modify the APK or inject calls via reflection. Always credit server-side after postback validation. The client callback should only update the UI to show a pending or confirmed reward — it should never modify the balance directly.

How often should I rotate my postback secret key?

Rotate at least every 6 months, and immediately if you suspect compromise. Perkox supports key rotation with a grace period where both old and new keys are accepted, so you can deploy the new key to all your servers without downtime. Plan the rotation during a low-traffic period.

Can IP whitelisting alone secure my postback endpoint?

No. IP whitelisting stops random traffic from reaching your endpoint, but it does not protect against spoofed IPs, compromised Perkox infrastructure (extremely unlikely but possible), or someone on the same network. Always combine IP whitelisting with signature verification, timestamp checks, and idempotency for defense in depth.

What should I do if I detect a fraud spike?

First, check the Perkox dashboard’s fraud signals view to identify the pattern (emulator farm, proxy traffic, multi-accounting). Then: tighten SDK security settings (enable stricter emulator/root detection), consider temporarily holding high-value rewards for manual review, and contact Perkox support with the affected transaction IDs. Do not block all postbacks — that punishes legitimate users.

Does the Perkox SDK detect iOS jailbreaks as well as Android roots?

Yes. The Perkox SDK includes jailbreak detection for iOS with the same risk-scoring framework as Android root detection. Jailbroken devices are flagged with a higher risk score, which can trigger reduced offer inventory, additional verification, or blocking depending on your configuration. The detection methods are updated regularly to keep pace with new jailbreak tools.

Secure Your Integration Today

Security is an ongoing process, not a one-time setup. Review your integration against the checklist above, close any gaps, and make monitoring a weekly habit.

• Start securing your offerwall: Access the Perkox publisher dashboard
• Security API reference: Perkox developer documentation
• Postback implementation: Complete postback guide
• Fraud signal reference: Fraud signals for publishers

Build your integration with security as the foundation, and you will spend your time optimizing revenue instead of chasing fraudsters.