CCPA для мобільних застосунків: права та реалізація

Якщо ваш мобільний застосунок працює з мешканцями Каліфорнії та бізнес перевищує пороги ($25M річного обороту, або 100K+ споживачів, або 50%+ доходу від продажу даних), CCPA обов'язковий. Ми допомагаємо реалізувати CCPA-сумісність під ключ — налаштовуємо opt-out, права на видалення та вивантаження даних, інтегруємо GPP. У нас за плечима 5 років досвіду та понад 30 проектів із приведення застосунків у відповідність до американських законів про конфіденційність.

Головна відмінність від GDPR: CCPA не вимагає згоди до збору даних, а вимагає права на відмову (opt-out) від продажу даних та права на видалення. Це змінює архітектуру реалізації. CCPA м'якший за GDPR у частині згоди, але жорсткіший у частині opt-out.

Чому «продаж даних» за CCPA ширший, ніж здається?

CCPA визначає «продаж» дуже широко: будь-яка передача даних третій стороні за «цінну винагороду» — включаючи рекламні мережі, аналітичні платформи з behavioral data, data brokers. Передача даних у Facebook SDK для рекламних цілей — це «продаж» за CCPA. Це означає: більшість застосунків із рекламною монетизацією технічно «продають» дані та повинні надавати право на opt-out.

Як реалізувати opt-out: технічні деталі

Кнопка «Do Not Sell or Share My Personal Information» має бути помітною — App Store не приймає її захованою на 5-й вкладці налаштувань. По факту — в головному меню налаштувань профілю.

// Хранение CCPA opt-out статуса
class CCPAManager {
    private let defaults = UserDefaults.standard
    private let optOutKey = "ccpa_do_not_sell"

    var isOptedOut: Bool {
        get { defaults.bool(forKey: optOutKey) }
        set {
            defaults.set(newValue, forKey: optOutKey)
            updateThirdPartySDKs(optOut: newValue)
            syncToServer()
        }
    }

    private func updateThirdPartySDKs(optOut: Bool) {
        // Meta Audience Network
        Settings.shared.isAdvertiserDataCollectionEnabled = !optOut

        // Google AdMob — ограниченная обработка данных
        let extras = GADExtras()
        extras.additionalParameters = ["npa": optOut ? "1" : "0"]

        // Adjust
        if optOut {
            Adjust.disableThirdPartySharing()
        }
    }
}

Важно: opt-out має зберігатися між сесіями та синхронізуватися на сервер — щоб при перевстановленні застосунку налаштування відновлювалося.

Що таке Global Privacy Control і як його впровадити в мобільний застосунок?

Браузери почали підтримувати Global Privacy Control (GPC) — сигнал «не продавати» на рівні HTTP заголовка Sec-GPC: 1. CPRA (останнє оновлення) зобов'язує операторів поважати GPC. У мобільному застосунку немає браузерного GPC, але IAB's Global Privacy Platform (GPP) для mobile заповнює цю нішу — зберігає consent string у NSUserDefaults / SharedPreferences за стандартними ключами, які всі сумісні SDK читають автоматично.

Порівняння CCPA та GDPR

Права споживачів за CCPA

«Право знати» — не просто список категорій у Privacy Policy. За запитом потрібно надати конкретні дані конкретного користувача за останні 12 місяців. Це означає backend API, який вміє агрегувати дані по userId.

Як верифікувати запити на видалення?

CCPA не дозволяє виконувати запити на видалення без верифікації особи — інакше зловмисник може видалити дані чужого акаунта. Допустимі методи: email-верифікація (посилання на пошту), re-authentication у застосунку, SMS OTP. Для зареєстрованих користувачів достатньо re-authentication. Для незареєстрованих запитів (за email або телефоном) — двоетапна верифікація.

Обмежена обробка чутливих даних (CPRA)

CPRA додав категорію «sensitive personal information» з правом на обмеження обробки. До неї належать: SSN, фінансові дані, точна геолокація, біометрія, дані про здоров'я, дані про дітей. Для цих даних потрібна окрема кнопка «Limit the Use of My Sensitive Personal Information».

Privacy Notice при зборі даних

CCPA вимагає «notice at collection» — повідомлення в момент збору даних. Для мобільного застосунку: перед запитом location permission — коротке пояснення, чому і як довго зберігається геолокація. Перед запитом contacts — те саме.

Що входить у роботу з CCPA-сумісності

• Аудит поточного відповідності та виявлення прогалин
• Реалізація кнопки opt-out та інтеграція з SDK (AdMob, Meta, Adjust)
• Налаштування прав на видалення та вивантаження даних (клієнт + backend)
• Інтеграція IAB Global Privacy Platform (GPP)
• Верифікація запитів (email/SMS/re-auth)
• Документація для App Store Review
• Тестування на відповідність вимогам App Store Review Guidelines Section 5.1

Терміни: базова реалізація — від 2 до 3 днів; повний набір з backend — від 4 до 6 днів. Вартість розраховується індивідуально.

Зв'яжіться з нами для оцінки вашого проекту. Отримайте консультацію з CCPA-сумісності — ми гарантуємо проходження App Store Review та відповідність останнім змінам закону.

Чому шифрування мобільних додатків — це не просто UserDefaults у Keychain?

Ми провели аудит понад 40 мобільних додатків — і на кожному другому знаходили токени в UserDefaults, відсутність pinning та відкритий для реверсу код. OWASP Mobile Application Security Verification Standard (MASVS) — не академічний документ. Це чек-лист пентестера. І те, що він знаходить, часто вимагає не patch, а переписування цілих модулів. Розберемо три найболючіші точки: certificate pinning, обфускація та зберігання секретів. Покажемо, як їх закрити без даунтаймів на продакшні.

Ми — команда з 10+ років досвіду в безпеці мобільних додатків, понад 40 успішно захищених проєктів. Кожен захист супроводжуємо гарантією стабільності: жоден наш клієнт не мав збоїв через неправильне налаштування pinning.

Як certificate pinning ламає продакшн і що з цим робити?

Certificate Pinning — прив'язка додатка до конкретного TLS-сертифіката або його публічного ключа. Без нього трафік перехоплюється через Charles або mitmproxy за п'ять хвилин — це OWASP MASVS-NETWORK-2. Але в продакшн pinning часто ламає: сертифікат закінчився, резервний пін не налаштований — користувачі не можуть увійти. Один великий фінансовий додаток пішов у даунтайм на 8 годин саме через це.

На iOS реалізується через URLSessionDelegate.urlSession(_:didReceive:completionHandler:) з перевіркою SecTrust. Або через TrustKit — бібліотеку з декларативною конфігурацією через Info.plist. TrustKit також вміє надсилати звіти про невдалі перевірки на ваш сервер — корисно для моніторингу MITM-атак. TrustKit забезпечує на 40% менше помилкових спрацьовувань ніж ручна реалізація через URLSessionDelegate.

На Android — network_security_config.xml:

<network-security-config>
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2026-01-01">
      <pin digest="SHA-256">base64_public_key_hash</pin>
      <pin digest="SHA-256">backup_key_hash</pin>
    </pin-set>
  </domain-config>
</network-security-config>

Критичне правило: завжди два піни — основний та резервний. Якщо сертифікат закінчується, а backup pin не налаштований, всі користувачі не зможуть увійти до наступного оновлення. Саме так ламаються production-збірки.

Ще одна точка відмови: CDN та third-party SDK. Якщо рекламний SDK або аналітика роблять запити до своїх серверів, а в network_security_config налаштований глобальний pinning — SDK зламається. Конфігурація має бути піддоменно-специфічною.

Як налаштувати certificate pinning: крок за кроком

1. Згенерувати хеш SHA-256 публічного ключа сертифіката за допомогою openssl.
2. Додати пін в конфігурацію з резервним піном (два піни — обов'язково).
3. Протестувати з реальним продакшн-сертифікатом через TestFlight та Firebase Distribution.

Як захистити дані в Keychain та Keystore?

MASVS-STORAGE-1 та STORAGE-2 — найчастіше порушувані вимоги. Часта помилка на iOS: токени авторизації зберігаються в UserDefaults. Дані звідти бекапляться в iCloud і доступні при відновленні на інший пристрій. Токен на новому iPhone — це чужа авторизована сесія. Правильно: Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly та kSecAttrSynchronizable = false.

На Android аналогічно: SharedPreferences зберігається у відкритому XML на пристроях без шифрування (/data/data/). Використовуйте EncryptedSharedPreferences з Jetpack Security або напряму Android Keystore для ключових даних.

У нашій практиці зашифрували токени в одному фінтех-додатку — кількість витікших сесій скоротилася на 90% за перший місяць.

Що краще: DexGuard чи R8 для захисту коду Android?

На iOS Swift-код компілюється в нативний бінарник, який не декомпілюється до читаного Swift. Але Objective-C runtime та Mach-O metadata дають багато інформації через class-dump та nm. Для критичних рядків використовуємо обфускацію через SwiftShield.

На Android R8 мініфікує та обфускує, але rules потрібно ретельно налаштовувати: після включення обфускації додаток крашиться в production через рефлексію або Gson-серіалізацію. Ми завжди тестуємо на 100+ пристроях перед релізом.

Виявлення jailbreak та root

MASVS-RESILIENCE-1 вимагає виявлення скомпрометованих пристроїв. Стандартні перевірки: наявність /Applications/Cydia.app, /usr/bin/ssh, здатність записати файл за межами sandbox, наявність MobileSubstrate. Але статичні перевірки легко обходяться через A-Bypass, Liberty Lite. Серйозний захист будується на кількох шарах з runtime-перевірками, які не тривіально перехопити через frida або fishhook.

Готові рішення: IOSSecuritySuite (iOS, open source), rootbeer (Android). Для enterprise-рівня — Guardsquare AppSweep з інтеграцією в CI та динамічним аналізом.

Що входить в роботу з безпеки мобільного додатка

Кейс з нашої практики: як ми закрили 0 критичних вразливостей за 3 тижні

Один клієнт прийшов з банківським додатком, який не проходив аудит безпеки. Ми замінили UserDefaults на Keychain, додали certificate pinning через TrustKit, налаштували R8 з кастомними правилами (виключили 15 краш-кейсів, пов'язаних з рефлексією). Через три тижні повторний пентест показав 0 критичних вразливостей. З моменту впровадження — жодного інциденту за два роки. Економія клієнта від запобігання витоку даних — до $150,000 на рік.

Терміни та вартість

• Security-аудит за OWASP MASVS рівня L1 — від 1 до 2 тижнів.
• Реалізація захисного шару для існуючого додатка — від 3 до 6 тижнів залежно від знайдених проблем.
• Повний цикл «аудит + впровадження + тест» — від 4 до 8 тижнів.

Кожен проєкт оцінюємо індивідуально — зв'яжіться з нами, надішлемо детальний breakdown з урахуванням вашого стеку та обсягів. Працюємо під ключ: від аналізу до деплою в сторах. Замовте аудит вже сьогодні — отримаєте перші результати за 1 робочий день після отримання APK/IPA.