Безпека iOS-застосунків: практики, які має знати кожен iPhone-розробник

Більшість iPhone-застосунків поводяться з даними користувачів недбало. Помилка в безпеці шкодить людям, руйнує вашу репутацію, а іноді ще й порушує закон. Ось той мінімум, який має закрити кожен iOS-розробник, — від зберігання даних і автентифікації до мережевого захисту та чистих релізних збірок.

Зберігання даних: тут помиляється більшість застосунків

Для чутливих даних — Keychain

UserDefaults не є захищеним сховищем. Це звичайний plist-файл. Прочитати його може будь-хто, у кого є доступ до пристрою або до резервної копії.

Облікові дані, токени й усе чутливе зберігайте в Keychain. Без винятків. Якщо ваш застосунок тримає токен автентифікації в UserDefaults, виправте це сьогодні.

• Для токенів, які не мають переживати відновлення пристрою, ставте kSecAttrAccessibleWhenUnlockedThisDeviceOnly.
• Ніколи не зберігайте паролі. Зберігайте токени. Обмежуйте термін їхньої дії. Оновлюйте їх.

Шифруйте чутливі файли

Якщо застосунок пише на диск чутливі дані — документи, кешовані відповіді, дані користувача, — вмикайте Data Protection в iOS. Ставте NSFileProtectionComplete на файли, які мають бути доступні лише тоді, коли пристрій розблоковано.

Core Data і SwiftData теж підтримують Data Protection. Вмикайте його в entitlements, а не лише в коді.

Мережева безпека

HTTPS усюди

App Transport Security (ATS) за замовчуванням вимагає HTTPS в iOS. Не вимикайте це. І не додавайте винятків NSAllowsArbitraryLoads, якщо у вас немає задокументованої причини.

TLS 1.2 — мінімум. TLS 1.3 — там, де його підтримує ваш сервер.

Пінінг сертифікатів для чутливих сценаріїв

Якщо застосунок працює з фінансовими чи медичними даними або з автентифікацією — робіть пінінг сертифікатів. Це зупиняє атаки типу man-in-the-middle навіть тоді, коли пристрій довіряє зловмисному центру сертифікації.

Реалізувати пінінг можна через URLSession із власним URLSessionDelegate. Бібліотеки на кшталт TrustKit беруть важку частину на себе, якщо ви не хочете підтримувати це вручну.

Пінінг потрібен не кожному застосунку. Але медицині, фінтеху й усьому, що має справу з чутливими даними користувачів, — так.

Автентифікація

Використовуйте OAuth 2.0 з PKCE

Не пишіть власну автентифікацію. Для входу користувачів беріть OAuth 2.0 з PKCE (Proof Key for Code Exchange). Це нинішній стандарт, і він унеможливлює атаку з перехопленням коду авторизації.

Браузерний сценарій входу коректно відпрацьовує ASWebAuthenticationSession від Apple. Користуйтеся ним.

Біометрична автентифікація

Face ID та Touch ID працюють через фреймворк Local Authentication. Беріть їх для локального розблокування застосунку, а не замість серверної сесії. Біометрія підтверджує власника пристрою — не власника облікового запису.

Вхід з Apple

Якщо ваш застосунок підтримує вхід через сторонні сервіси (Google, Facebook тощо), Apple вимагає додати «Вхід з Apple» як один із варіантів. Для користувачів це справді корисно: жодного збирання email-адрес, вбудований приватний ретранслятор пошти. Реалізуйте його як слід, а не для галочки.

API-ключі та секрети

Не кладіть секрети в бандл застосунку. Ніколи.

• API-ключі в коді витягують із бінарника. Це елементарно. Не робіть так.
• Секретам місце на вашому бекенді. Застосунок автентифікується до вашого бекенду, а бекенд уже звертається до стороннього API.
• Для ключів, які мусять жити на пристрої (SDK аналітики тощо), застосовуйте обфускацію — це не безпека, але вона піднімає планку.

Перед кожним релізом перевіряйте кодову базу на захардкоджені API-ключі. Ловіть їх у CI за допомогою git-secrets чи схожого інструмента.

Приватність користувачів

Просіть лише те, що вам справді потрібно

Кожен запит дозволу — камера, геолокація, контакти — має мати зрозумілий текст пояснення. Apple їх перевіряє. Користувачі їх читають. Розмиті формулювання відхиляють, а надто жадібні дозволи ведуть до видалення застосунку.

Просіть дозволи в момент використання, а не на старті. Запит геолокації на першому екрані, ще до пояснення навіщо вона, гарантовано отримає відмову.

Мітки приватності в App Store

Сторінка вашого застосунку в App Store вимагає точних міток приватності. За неправду в них застосунок знімають з продажу. Перевірте, які дані збирають ваші сторонні SDK: аналітичні та рекламні часто забирають більше, ніж ви думаєте.

Ризики на рівні коду

Валідація вхідних даних

Перевіряйте все, що приходить від користувача або з мережі. Не розраховуйте, що сервер це відловить. Не розраховуйте, що обмежень в інтерфейсі досить. Валідуйте на рівні моделі.

Виявлення джейлбрейку

Для застосунків з високими вимогами до безпеки (банкінг, медицина) додайте виявлення джейлбрейку. Це не панацея, але підвищує вартість атаки. Перевіряйте типові шляхи джейлбрейку, наявність Cydia та порушення пісочниці.

Вимикайте зневаджувальні логи в продакшені

Докладні логи в релізних збірках — це ризик для безпеки. Вирізайте зневаджувальний вивід умовною компіляцією: #if DEBUG ... #endif. Ніколи не логуйте токени, паролі чи персональні дані — навіть у зневаджувальних збірках.

Безпека збірки та розгортання

• Вмикайте Hardened Runtime для застосунків Mac Catalyst.
• Підписуйте всі збірки. Непідписану збірку можна підробити.
• Точно заповнюйте інформацію про експортну відповідність в App Store Connect. Більшість застосунків підпадає під стандартний виняток щодо шифрування.
• Змінюйте облікові дані щоразу, коли хтось залишає команду.

З чого почати

Якщо ви перевіряєте наявний застосунок, дійте в такому порядку:

1. Зберігання облікових даних — перенесіть усе чутливе з UserDefaults у Keychain.
2. Мережева безпека — переконайтеся, що HTTPS усюди й немає винятків ATS.
3. API-ключі — знайдіть і приберіть усе захардкоджене.
4. Мітки приватності — перевірте, що насправді збирають ваші SDK.
5. Валідація вхідних даних — додайте перевірки на рівні моделі для полів, які заповнює користувач.

Не намагайтеся полагодити все одразу. Спершу критичне, далі системно все інше.

Коли варто залучити фахівців

Аудит безпеки від профільних спеціалістів окупається перед великим запуском, раундом інвестицій або виходом у регульовану галузь. Хороший аудит показує те, чого ваша команда вже не бачить, бо надто близька до кодової бази.

В Applefy ми закладаємо безпеку від старту, а не докручуємо потім. Якщо вам дісталася чужа кодова база і потрібна чесна оцінка — напишіть нам.

Часті запитання

Яка найчастіша помилка безпеки в iOS?

Зберігання облікових даних у UserDefaults замість Keychain. Це те, що ми найчастіше бачимо на код-рев’ю, і водночас найпростіше у виправленні.

Чи кожному застосунку потрібен пінінг сертифікатів?

Ні. Пінінг має сенс для застосунків, що працюють із фінансовими даними, медичними записами або токенами автентифікації. Для більшості споживчих застосунків досить звичайного HTTPS.

Як перевірити, чи є в застосунку захардкоджені API-ключі?

Пошукайте в кодовій базі типові патерни: рядки, що закінчуються на _key, _secret, _token. Запустіть на репозиторії git-secrets або trufflehog. Перевірте конфігурації сторонніх SDK.

Що буде, якщо застосунок не пройде перевірку міток приватності Apple?

Apple відхилить збірку й попросить виправити мітки перед повторною подачею. Систематична неточність може призвести до видалення застосунку з App Store.

Чи обов’язково впроваджувати «Вхід з Apple»?

Так, якщо застосунок підтримує будь-який вхід через сторонній сервіс (Google, Facebook, Twitter тощо). У таких випадках Apple вимагає запропонувати «Вхід з Apple» як один із варіантів.