Szyfrowanie danych w aplikacjach mobilnych salonów meblowych: checklist dla IT

Kontekst salonu meblowego: jakie dane faktycznie wymagają szyfrowania

Rodzaje aplikacji mobilnych w salonach meblowych

W typowym ekosystemie salonu meblowego funkcjonuje kilka różnych aplikacji mobilnych i każda z nich ma inny profil ryzyka. Inaczej szyfruje się dane w aplikacji zakupowej dla klientów, a inaczej w wewnętrznym narzędziu dla sprzedawców lub magazynierów. Porządkowanie zagadnienia od strony typów aplikacji pomaga nie gubić się w szczegółach technicznych.

Najczęściej spotykane są trzy kategorie:

• Aplikacje dla klientów – konfiguratory, aplikacje zakupowe, przegląd katalogu, wizualizacje AR, wirtualne aranżacje pomieszczeń, śledzenie zamówienia. Zwykle zawierają dane klientów, ich historię przeglądania i zamówień, zapamiętane koszyki, adresy dostaw.
• Aplikacje sprzedażowe / CRM – narzędzia używane przez doradców na sali sprzedaży: wgląd w historię klienta, indywidualne rabaty, zamówienia w toku, notatki handlowe, dane B2B, a czasem dane finansowe (zdolność kredytowa, wnioski ratalne, integracje z leasingiem).
• Aplikacje magazynowe i logistyczne – obsługa stanów magazynowych, przyjęć, wydań, kompletacji, skanowanie kodów, planowanie dostaw i montaży. Dane są bardziej „operacyjne”, ale często bardzo wrażliwe biznesowo (stany magazynowe, dostawy, koszty logistyki, marże produktowe).

W każdej z tych kategorii trzeba osobno przeanalizować, jakie dane pojawiają się w aplikacji, gdzie są przechowywane i jak długo. Bez tej wiedzy nawet najlepsza technika szyfrowania będzie przykładała się do niekoniecznie kluczowych obszarów, a wrażliwe informacje pozostaną odsłonięte.

Dane najbardziej wrażliwe z perspektywy RODO i klientów

W salonach meblowych przetwarzanie danych osobowych jest intensywne: klienci zostawiają swoje dane do zakupu, transportu, montażu, reklamacji, programów lojalnościowych, personalizowanych ofert czy projektów wnętrz. Z perspektywy szyfrowania szczególnie istotne są:

• Dane identyfikacyjne – imię, nazwisko, PESEL (jeśli jest zbierany np. do rat), NIP, dane firmy klienta B2B.
• Dane adresowe – adresy dostaw, adresy korespondencyjne, dane do faktury. Na ich podstawie można łatwo zidentyfikować miejsce zamieszkania klienta.
• Dane kontaktowe – numery telefonów, e-maile. Ich wyciek prowadzi do phishingu, spamowania, podszywania się pod salon.
• Historia zakupów i preferencje – informacje o tym, co klient kupił, co przegląda, jakie ma preferencje stylistyczne, budżet. Dla klienta to część prywatnego życia domowego, której nie życzy sobie w cudzych rękach.
• Dane płatnicze lub pośrednie – tokeny kart płatniczych (jeśli występują), identyfikatory transakcji, dane potrzebne do obsługi rat lub leasingu.

Z punktu widzenia RODO szyfrowanie nie zwalnia z innych obowiązków, ale istotnie zmniejsza skutki potencjalnego incydentu. Dane zaszyfrowane mocnym algorytmem, przy braku dostępu do klucza, często uznawane są za „praktycznie nieczytelne”, co wpływa na ocenę ryzyka i działania naprawcze.

Dane krytyczne biznesowo: co boli firmę, nawet jeśli to nie są dane osobowe

Salon meblowy to biznes o silnej konkurencji cenowej i promocyjnej. Utrata niektórych informacji nie zniszczy reputacji u klientów, ale może poważnie uderzyć w przewagi konkurencyjne. Tego typu dane także powinny być objęte szyfrowaniem, szczególnie w aplikacjach mobilnych dla sprzedawców i kadry zarządzającej.

Do danych krytycznych biznesowo należą przede wszystkim:

• Struktury rabatowe i cenniki B2B – indywidualne warunki dla deweloperów, hoteli, biur, architektów wnętrz. Ich wyciek do konkurencji to realna strata.
• Marże i koszty zakupu – dane o tym, ile salon faktycznie płaci producentom i jaką marżę stosuje. Ujawnienie takich informacji osłabia pozycję negocjacyjną.
• Warunki umów z dostawcami – terminy płatności, wolumeny, preferencyjne warunki logistyczne, ekskluzywność produktów.
• Plany promocji i kampanii – przyszłe wyprzedaże, wprowadzenia kolekcji, akcje lojalnościowe. Konkurent z takim wglądem może lepiej dostosować własne działania.

Te informacje bywają przechowywane lub podglądane w aplikacjach CRM, aplikacjach dla menedżerów lub wewnętrznych dashboardach dostępnych mobilnie. Jeśli takie narzędzia działają na telefonach lub tabletach, szyfrowanie storage’u i bezpieczne zarządzanie sesją staje się elementem ochrony tajemnicy przedsiębiorstwa.

Mapowanie przepływu danych: fundament pod sensowną checklistę

Przed decyzją, co i jak szyfrować, trzeba wiedzieć, gdzie dokładnie wędrują dane. Proste ćwiczenie mapowania przepływów pomaga wyjść poza ogólne deklaracje typu „szyfrujemy wszystko” i faktycznie zabezpieczyć krytyczne punkty. Dla aplikacji mobilnej salonu meblowego takie mapowanie obejmuje kilka obszarów:

• Miejsca powstawania danych – formularze w aplikacji klienta, ekran dodawania rabatu przez sprzedawcę, skanowanie kodu w magazynie, zaciąganie danych z zewnętrznego systemu ratalnego.
• Miejsca przetwarzania – front-end (aplikacja mobilna), backend API, zewnętrzne integracje (płatności, raty, analityka, marketing automation), wewnętrzne systemy (ERP, CRM, WMS).
• Miejsca przechowywania – pamięć urządzenia (cache, lokalna baza, pliki), sesje w pamięci, bazy danych po stronie serwera, logi systemowe, backupy, narzędzia do monitoringu i analityki.
• Miejsca „wycieku bocznego” – logi debugowe, zrzuty ekranu, notatki w komunikatorach, pliki eksportowane do Excela, testowe kopie baz na środowiskach deweloperskich.

Tylko pełniejsze spojrzenie na ten „łańcuch życia” danych pozwala stwierdzić, w których punktach potrzebne jest szyfrowanie w spoczynku, gdzie – szyfrowanie w tranzycie, a gdzie – dodatkowe mechanizmy typu tokenizacja lub pseudonimizacja.

Model zagrożeń dla aplikacji mobilnych salonu meblowego

W salonie meblowym zestaw zagrożeń jest inny niż w banku, ale kilka scenariuszy powtarza się bardzo często. Prosty model zagrożeń można zbudować na bazie kilku praktycznych przypadków:

• Zgubiony lub skradziony telefon sprzedawcy – urządzenie ma zainstalowaną aplikację CRM, zapisane loginy, dostęp offline do danych klientów, rabatów, historii transakcji. Jeśli dane nie są szyfrowane i nie ma blokady aplikacji, napastnik po złamaniu blokady ekranu ma pełny wgląd w informacje.
• Złośliwa aplikacja na telefonie klienta – klient ma na swoim smartfonie aplikacje z malware, które próbują przechwytywać ruch lub odczytywać dane z pamięci. Źle zaimplementowane szyfrowanie lub zapisywanie danych w prostych plikach otwiera im drogę do kradzieży danych osobowych.
• Nieautoryzowany dostęp do API – ktoś odtwarza mechanizmy komunikacji aplikacji z API, wykorzystuje brak szyfrowania lub słabe uwierzytelnianie, podmienia żądania, masowo pobiera katalog klientów lub stany magazynowe.
• Wyciek backupu – kopia zapasowa bazy danych trzymana w chmurze lub na dysku dewelopera, bez szyfrowania, trafia w niepowołane ręce. W środowisku mobilnym często zapomina się, że analityka, crash logi i backupy również mogą zawierać dane umożliwiające identyfikację użytkownika.

Przy projektowaniu checklisty dla IT dobrze jest spisać kilka takich scenariuszy i pod każdy z nich wypisać: jakie dane są narażone, które mechanizmy szyfrowania pomagają, a które warstwy (mobilna, serwerowa, sieciowa) wymagają szczególnej uwagi.

Podstawy szyfrowania dla IT w prostych słowach

Szyfrowanie, maskowanie, hashowanie, tokenizacja – gdzie co użyć

W aplikacjach mobilnych salonu meblowego nie zawsze potrzebne jest szyfrowanie w klasycznym sensie. Czasem lepsze są inne techniki: hashowanie lub tokenizacja. Dobrze je odróżnić, żeby nie wprowadzić zbyt skomplikowanych rozwiązań tam, gdzie wystarcza prostsze podejście.

• Szyfrowanie – proces odwracalny. Dane (np. adres, rabat, dane zamówienia) zaszyfrowane kluczem mogą zostać odszyfrowane, jeśli znamy ten klucz. Stosowane, gdy aplikacja musi później odczytać dane (np. historia zamówień, szczegóły klienta).
• Hashowanie – proces jednokierunkowy (np. BCrypt, Argon2). Używany głównie do przechowywania haseł lub weryfikacji integralności. W salonie meblowym sprawdzi się np. do bezpiecznego przechowywania haseł sprzedawców lub klientów.
• Maskowanie – ukrywanie części danych przy prezentacji, np. 1234••••••78 w numerze karty czy 600•••••• w numerze telefonu. Maskowanie chroni przed podglądaniem ekranu przez osoby trzecie, ale nie przed wyciekiem danych z systemu.
• Tokenizacja – zamiana danych wrażliwych na tokeny, które same w sobie nie mają wartości (np. token karty płatniczej z systemu płatniczego). Stosowana przy integracji z operatorami płatności – aplikacja nigdy nie „widzi” pełnego numeru karty, tylko token.

Szyfrowanie danych w aplikacjach mobilnych salonów meblowych ma największy sens tam, gdzie dane muszą pozostać odczytywalne dla systemu, ale nie dla osoby, która uzyska fizyczny lub logiczny dostęp do urządzenia czy bazy danych.

Szyfrowanie symetryczne i asymetryczne: jak to praktycznie wykorzystać

Kluczowe rozróżnienie przy projektowaniu szyfrowania to wybór między algorytmami symetrycznymi i asymetrycznymi. W praktyce mobilnej najczęściej stosuje się kombinację obu.

• Szyfrowanie symetryczne – ten sam klucz służy do szyfrowania i odszyfrowania danych. Najpopularniejszy standard to AES (np. AES‑256 w trybie GCM lub CBC z poprawną walidacją MAC). W aplikacji mobilnej:
  • używane do szyfrowania lokalnych baz danych (SQLite, Realm), plików i cache’u,
  • stosowane po stronie serwera dla danych w bazie (szyfrowanie w spoczynku).
• Szyfrowanie asymetryczne – różne klucze do szyfrowania (publiczny) i odszyfrowania (prywatny). Przykłady: RSA, ECC. Praktycznie:
  • używane w TLS do uzgadniania kluczy sesyjnych,
  • przydatne do bezpiecznej wymiany kluczy symetrycznych między aplikacją a serwerem,
  • czasem do podpisywania żądań API po stronie serwera lub w integracjach B2B.

Najczęstszy model to szyfrowanie hybrydowe: asymetryczne szyfruje jedynie klucze sesyjne, a same dane płyną szyfrowane symetrycznym AES. Daje to rozsądny kompromis między bezpieczeństwem a wydajnością – szczególnie ważny na starszych telefonach klientów czy pracowników.

Szyfrowanie w spoczynku, w tranzycie i „w użyciu”

Dane w cyklu życia pojawiają się w trzech stanach, które trzeba brać pod uwagę w checkliście:

• W spoczynku (at rest) – zapisane na dysku: w bazie, plikach, cache’u, backupach. Dotyczy to zarówno urządzenia mobilnego (lokalna baza, pliki z projektami wnętrz), jak i backendu (baza klientów, logi, backupy). Szyfrowanie chroni przed atakami na urządzenie, kradzieżą lub wyciekiem kopii zapasowych.
• W tranzycie (in transit) – w trakcie przesyłania przez sieć między aplikacją a API, systemami płatności, CRM czy ERP. Tutaj podstawą jest TLS 1.2+ oraz poprawna konfiguracja serwera. Ataki to m.in. podsłuch (sniffing) i man-in-the-middle.
• W użyciu (in use) – dane załadowane do pamięci RAM podczas pracy aplikacji. Ten obszar jest najtrudniejszy do pełnego zabezpieczenia. Można jednak stosować pewne praktyki: trzymać dane w pamięci jak najkrócej, zerować wrażliwe bufory, szyfrować pola w bazie, a przy prezentacji na ekranie maskować np. numery telefonów czy tokenty płatnicze.

W kontekście mobilnym najwięcej decyzji dotyczy szyfrowania „w spoczynku” na urządzeniu oraz „w tranzycie” do backendu. „W użyciu” to domena zaawansowanych zabezpieczeń (np. ochrona przed zrzutem pamięci na zrootowanym urządzeniu), ale nawet tu proste środki potrafią ograniczyć szkody.

Standardy i algorytmy, które mają sens w aplikacji mobilnej salonu meblowego

Żeby nie przepalać czasu na badanie wszystkich możliwych opcji, można oprzeć się na sprawdzonych standardach. W przypadku salonu meblowego, który nie jest instytucją finansową, zazwyczaj wystarczą następujące wybory:

Jakie algorytmy wybrać w praktyce

Wielu osobom temat algorytmów kojarzy się z kryptografią akademicką. W aplikacji mobilnej salonu meblowego da się to uprościć do kilku decyzji architektonicznych, które potem wracają jako pozycje w checkliście wdrożeniowej.

• Szyfrowanie symetryczne danych biznesowych:
  • po stronie urządzenia – AES‑256‑GCM lub AES‑256‑CBC + HMAC‑SHA‑256 (jeśli biblioteka nie wspiera GCM),
  • po stronie serwera – analogicznie AES‑256‑GCM/CBC, najlepiej w ramach sprawdzonej biblioteki (libsodium, WebCrypto, biblioteki dostawcy chmury).
• Hashowanie haseł:
  • do kont pracowników i klientów – Argon2id lub BCrypt z odpowiednim kosztem,
  • do identyfikatorów analitycznych – ewentualnie SHA‑256 z solą, jeśli hashowanie ma służyć jedynie pseudonimizacji ID.
• Transport:
  • TLS 1.2+ jako absolutny standard, a najlepiej TLS 1.3 dla nowych wdrożeń,
  • zestaw mocnych szyfrów (cipher suites) bez archaicznych opcji typu RC4, 3DES, bez nieprawidłowego fallbacku.
• Podpisy i wymiana kluczy:
  • dla podpisywania tokenów – HS256/HS512 (z tajnym kluczem serwera) lub RS256/ES256 (z parą kluczy publiczny/prywatny),
  • dla integracji B2B – RSA 2048+ lub krzywe eliptyczne (np. ECDSA/ECDH na P‑256), zgodnie z polityką dostawcy.

Dobrym nawykiem jest unikanie „wymyślania” własnych algorytmów i formatów. Zazwyczaj bezpieczniej (i taniej w utrzymaniu) jest oprzeć się na standardach rekomendowanych przez OWASP i dostawców chmury, niż próbować projektować autorskie formaty kryptograficzne.

Dane na urządzeniu użytkownika: co, gdzie i jak szyfrować

Mapa danych w aplikacji mobilnej salonu meblowego

Zanim na checkliście pojawią się konkretne biblioteki szyfrujące, warto mieć w głowie prostą mapę tego, co w ogóle ląduje na telefonie klienta lub sprzedawcy. Z perspektywy aplikacji mobilnej typowe kategorie to:

• Dane konfiguracyjne – język, preferencje UI, ostatnio otwarty salon, ustawienia filtrów katalogu.
• Dane sesyjne i uwierzytelniające – tokeny JWT, refresh tokeny, identyfikator użytkownika, czas wygaśnięcia sesji, czasem zaszyfrowane ciasteczka.
• Dane klienta – imię, nazwisko, telefon, e‑mail, adres dostawy, zgody marketingowe, preferencje.
• Dane transakcyjne – koszyk, historia zamówień, wyceny, oferty indywidualne, rabaty, informacje o dostawie.
• Dane projektowe – wizualizacje 3D, zdjęcia pomieszczeń, wymiary, notatki sprzedawcy.
• Telemetria i logi aplikacji – informacje o błędach, wykorzystaniu funkcji, identyfikatory urządzenia lub sesji.

Nie wszystko musi być zaszyfrowane. Ustawienia języka mogą leżeć w plaintext, ale token dostępu do API albo adres e‑mail klienta już nie. Przy tworzeniu checklisty pomagają dwie kolumny: „czy dane pozwalają zidentyfikować osobę?” oraz „czy pozwalają wykonać w jej imieniu istotne działanie (np. złożenie zamówienia)?”. Wystarczy jedna odpowiedź „tak”, by zacząć rozważać szyfrowanie na urządzeniu.

Lokalne bazy danych: SQLite, Realm i inne

W aplikacjach, które muszą działać offline (sprzedawca na hali, przedstawiciel w domu klienta), lokalna baza to standard. Bez szyfrowania baza SQLite czy Realm jest prostym plikiem, który po skopiowaniu z urządzenia otwiera się jedną komendą.

Przy projektowaniu szyfrowania lokalnej bazy warto przejść przez kilka pytań:

• Jakie tabele zawierają dane osobowe lub transakcyjne? Często da się ograniczyć szyfrowanie tylko do kolumn z danymi wrażliwymi, co bywa korzystne dla wydajności.
• Czy baza ma służyć głównie do cache’owania danych z API? Jeśli tak, w razie wycieku można odtworzyć dane po stronie serwera. Wtedy szyfrowanie pomaga głównie chronić prywatność, a nie krytyczne funkcje biznesowe.
• Czy aplikacja obsługuje wielu użytkowników na jednym urządzeniu? W salonach meblowych często tablety „krążą” między sprzedawcami. W takim modelu potrzebne jest dobre odseparowanie danych poszczególnych kont.

Typowe punkty na checkliście dla lokalnej bazy:

• wybór biblioteki z natywnym wsparciem szyfrowania (np. SQLCipher dla SQLite),
• szyfrowanie co najmniej kolumn z danymi osobowymi, detalami zamówień i rabatami klienta,
• klucz szyfrujący bazy trzymany w bezpiecznym magazynie kluczy systemu (Android Keystore, iOS Keychain),
• mechanizm rotacji klucza bazy (np. przy kolejnej aktualizacji aplikacji lub po określonym czasie),
• brak „awaryjnego” trybu debug z wyłączonym szyfrowaniem na produkcji.

Pliki i multimedia: wizualizacje, zdjęcia, dokumenty

Zdjęcia pomieszczeń, wizualizacje 3D czy pliki PDF z ofertą to dobra „pożywka” dla atakującego, ale też źródło stresu dla klientów – mało kto życzy sobie, by ktoś postronny miał wgląd w plany mieszkania. Z drugiej strony, pełne szyfrowanie każdego pliku może obciążać starsze urządzenia.

Praktyczne podejście, które zazwyczaj się sprawdza:

• Pliki stricte marketingowe (katalogi offline, zdjęcia produktów) – można przechowywać bez szyfrowania, o ile nie zawierają danych klienta.
• Pliki powiązane z konkretnym klientem – zdjęcia wnętrz, notatki, szkice – powinny być:
  • przechowywane w wydzielonym katalogu aplikacji,
  • zaszyfrowane kluczem aplikacyjnym (AES‑GCM),
  • usuwane po określonym czasie lub po zakończeniu projektu, jeśli nie są potrzebne offline.
• Pliki generowane „na chwilę” (np. pdf wyceny) – można generować wyłącznie w pamięci i wysyłać przez TLS do klienta e‑mailem lub do serwera, bez pozostawiania kopii w pamięci masowej.

Na checkliście dobrze dodać pozycję „przegląd katalogów aplikacji pod kątem niezaszyfrowanych plików” – to jedno z miejsc, które często wypadają z przeglądu bezpieczeństwa.

Bezpieczne przechowywanie tokenów i danych logowania

Najczęstszy ból głowy w mobilnym świecie to „gdzie trzymać tokeny, żeby aplikacja mogła wygodnie działać, a jednocześnie nie ułatwić pracy atakującemu”. Uspokajające jest to, że zarówno Android, jak i iOS dają wbudowane mechanizmy, które mocno pomagają.

• Android:
  • przechowywanie kluczy i sekretów w Android Keystore,
  • zaszyfrowane preferencje (EncryptedSharedPreferences) do tokenów i ustawień,
  • możliwość powiązania dostępu z blokadą ekranu (PIN, odcisk palca, biometria).
• iOS:
  • magazyn kluczy Keychain z klasami dostępu (np. dostępny tylko przy odblokowanym urządzeniu),
  • powiązanie z Face ID / Touch ID dla szczególnie wrażliwych operacji (np. zatwierdzenie zakupu).

Dobrą praktyką jest:

• przechowywać tylko refresh token w bezpiecznym magazynie, a access token trzymać głównie w pamięci (i odświeżać go, gdy wygaśnie),
• nie zapisywać haseł wprost – logowanie realizować najlepiej przez tokeny lub zewnętrznego dostawcę (SSO, social login, B2B SAML/OIDC),
• czyścić tokeny przy ręcznym wylogowaniu i przy stwierdzeniu kompromitacji (zmiana hasła, zgłoszenie utraty urządzenia).

Cache, pamięć podręczna i tryb offline

Cache często jest projektowany z myślą o wydajności, a kwestia prywatności pojawia się dopiero przy audycie. W aplikacji salonu meblowego cache bywa bardzo rozbudowany – katalogi, konfiguracje promocji, listy ulubionych produktów czy zapisane koszyki.

Kilka bezpiecznych zasad, które można wpisać w checklistę:

• Rozdzielenie cache’u publicznego i prywatnego – dane widoczne dla wszystkich (np. lista kolekcji) mogą być cache’owane wprost, natomiast dane indywidualne (ulubione, ostatnio oglądane, historia) powinny być szyfrowane lub ograniczone czasowo.
• Limit czasu życia cache’u wrażliwego – np. zapisany koszyk offline wygasa po określonej liczbie dni braku aktywności.
• Czyszczenie cache’u przy wylogowaniu – nie tylko tokeny, ale też powiązane dane użytkownika.
• Ostrożność z cache’owaniem odpowiedzi API – szczególnie, gdy zawierają dane kontaktowe lub historię zakupów.

Przy pracy sprzedawcy offline dochodzi jeszcze kwestia synchronizacji. Z perspektywy bezpieczeństwa bardzo pomaga zasada: „synchronizujemy to, co niezbędne, trzymamy to możliwie krótko, szyfrujemy to, co identyfikujące”.

Transmisja danych: bezpieczna komunikacja z API, płatnościami i panelem sklepu

Minimalne wymagania dla połączeń TLS

Na poziomie kodu mobilnego często zakłada się, że „HTTPS wystarczy”. Tymczasem wiele incydentów wynika nie z braku HTTPS, ale z jego błędnej konfiguracji lub zaufania do dowolnego certyfikatu, jaki poda system.

Kilka technicznych punktów, które dobrze mieć w standardzie:

• Wymuszenie TLS 1.2+ – w konfiguracji serwera i klienta; jeśli biznes nie ma szczególnej potrzeby wspierania bardzo starych urządzeń, TLS 1.0/1.1 można wyłączyć.
• Wyłączenie niebezpiecznych pakietów szyfrów – brak wsparcia dla anonimizowanych pakietów (bez uwierzytelniania), brak RC4 i 3DES.
• Poprawna weryfikacja certyfikatu po stronie aplikacji – bez wyłączania walidacji w trybie „na skróty” w buildach produkcyjnych.
• Aktualne certyfikaty – monitorowanie ważności certyfikatów i automatyczne odnowienie (np. Let’s Encrypt, usługi chmurowe).

Certificate pinning i ochrona przed man‑in‑the‑middle

W aplikacjach, gdzie bezpieczeństwo sesji klienta jest kluczowe (zakupy na kredyt, dostęp do historii zamówień, dane adresowe), rozsądnie jest dodać warstwę ochrony przed przechwytywaniem ruchu na poziomie urządzenia czy sieci Wi‑Fi. Temu służy certificate pinning.

W największym skrócie: aplikacja nie ufa „dowolnemu certyfikatowi, który system uzna za poprawny”, lecz ma wbudowaną informację o tym, który certyfikat (lub który klucz publiczny) jest prawidłowy dla API. Jeśli ktoś spróbuje podstawić własny certyfikat, aplikacja odrzuci połączenie.

W praktyce warto:

• pinować nie pojedynczy certyfikat, lecz klucz publiczny lub certyfikat CA (żeby nie trzeba było aktualizować aplikacji przy każdym odnowieniu certyfikatu),
• dodać mechanizm bezpiecznej aktualizacji pinów – np. przez podpisaną konfigurację z serwera,
• zachować co najmniej dwa piny (aktualny i zapasowy), aby móc rotować certyfikaty bez przestojów.

W checkliście warto dopisać również pozycję „test połączeń z włączonym pinningiem z różnych sieci (Wi‑Fi, LTE, sieć sklepu)” – pozwala to wyłapać błędy w konfiguracji przed wdrożeniem.

Bezpieczna komunikacja z API sklepu i panelami wewnętrznymi

API obsługujące aplikację klienta oraz panele dla sprzedawców i kierowników salonu są szczególnie atrakcyjnym celem. Dają dostęp do pełnych danych klientów, historii zakupów, rabatów i informacji o stanie magazynowym.

Oprócz samego szyfrowania połączenia warto zadbać o kilka dodatkowych warstw:

• Silne uwierzytelnienie:
  • dla klientów – tokeny (np. JWT) z krótkim czasem ważności, odświeżane przez refresh token,
  • dla pracowników – często SSO (Azure AD, Google Workspace), ewentualnie 2FA dla dostępu do paneli z danymi wrażliwymi.

Integracje płatności i banków: osobne zasady gry

Gdy w grę wchodzą raty, kredyty lub płatności online, poziom ryzyka znacznie rośnie. Na szczęście większość ciężaru zgodności (PCI DSS, PSD2 itp.) biorą na siebie operatorzy płatności i banki – pod warunkiem, że aplikacja nie próbuje „mądrzejszych” skrótów.

Bezpieczny model to możliwie cienka warstwa integracji po stronie aplikacji: