Bảo Mật Ứng Dụng Di Động: 10 Rủi Ro, Checklist & Release Gate

Bảo mật ứng dụng di động không phải lớp “gia cố” thêm vào sau khi app đã hoàn thành. Nó là cách doanh nghiệp thiết kế dữ liệu, tài khoản, API, thiết bị, chuỗi cung ứng phần mềm, quy trình phát hành và khả năng xử lý sự cố trong suốt vòng đời sản phẩm.

Một app có thể chạy ổn trong demo nhưng vẫn rò token, cho phép truy cập sai object, ghi dữ liệu nhạy cảm vào log hoặc tin quyết định do client gửi lên. Vì mobile client nằm trên thiết bị người dùng, doanh nghiệp phải giả định binary có thể bị quan sát, phân tích và sửa đổi; quyền và dữ liệu quan trọng cần được kiểm soát ở server.

Tóm tắt nhanh: Bắt đầu bằng data inventory và threat model; dùng OWASP MASVS làm baseline kiểm chứng mobile, đồng thời kiểm tra backend/API riêng. Ưu tiên secret, local storage, authentication, authorization, network, privacy, SDK/dependency, platform interaction, integrity và secure release. Không mở production khi rủi ro cao chưa có owner, biện pháp giảm thiểu và bằng chứng test.

Bảo mật app gồm những phạm vi nào?

Phạm vi	Cần bảo vệ	Ví dụ control
Mobile client	Dữ liệu cục bộ, token, component, WebView, deep link	Secure storage, platform config, input handling
Identity/session	Đăng nhập, recovery, token, thiết bị và step-up	Session lifecycle, MFA theo rủi ro, revoke
Backend/API	Object, role, business rule và rate	Server-side authorization, validation, audit
Network	Dữ liệu khi truyền và endpoint	TLS, certificate validation, timeout, replay protection
Data/privacy	PII, dữ liệu nhạy cảm, mục đích và retention	Minimization, encryption, access review, deletion
Supply chain	SDK, dependency, build và signing	Inventory, scanning, provenance, key protection
Operations	Monitoring, incident, patch và recovery	Alert, runbook, hotfix, backup/restore

OWASP MASVS cung cấp baseline kiểm chứng bảo mật và quyền riêng tư cho ứng dụng mobile; các test case thực hành nằm trong OWASP MASTG/MAS Checklist. MASVS không thay thế việc kiểm tra backend. Với authentication và authorization ở endpoint, OWASP cũng lưu ý cần xác minh remote endpoint bằng tiêu chuẩn phù hợp như ASVS. Tham khảo OWASP MASVS và MAS Checklist.

Trước khi test: lập data inventory và threat model

Không thể kiểm tra bảo mật có hệ thống nếu team chưa biết app xử lý dữ liệu gì và luồng quan trọng nào cần bảo vệ. Tối thiểu cần ghi lại:

• Loại dữ liệu, mức nhạy cảm, nguồn, nơi lưu, bên nhận và thời gian giữ.
• Trust boundary giữa app, API gateway, service, vendor và admin.
• Actor hợp lệ, actor độc hại và tài khoản nội bộ có quyền cao.
• User journey có tác động tiền, dữ liệu, quyền hoặc vận hành.
• Abuse case: credential stuffing, enumeration, coupon abuse, fake client, replay hoặc automation.
• Dependency và điều gì xảy ra khi vendor unavailable hoặc trả dữ liệu sai.

Threat model không cần là sơ đồ quá phức tạp. Giá trị nằm ở việc biến giả định thành risk, control, owner và test. Khi flow hoặc vendor thay đổi, threat model phải được cập nhật.

10 nhóm rủi ro bảo mật cần kiểm tra

Nhóm	Dấu hiệu	Control chính
1. Secret/credential	Key hardcode, token dài hạn, secrets trong log/build	Server-side secrets, scope, rotation, revoke
2. Local storage	PII/token/cache nằm ở nơi không phù hợp	Minimize, Keychain/Keystore, lifecycle và xóa
3. Network	HTTP, bỏ qua certificate, endpoint test	TLS, validation, environment separation
4. Authentication/session	Recovery yếu, session không revoke, thiếu step-up	Risk-based auth, token lifecycle, re-auth
5. Authorization/API	IDOR/BOLA, role do client quyết định	Object/action authorization ở server
6. Privacy/permission	Thu thừa, xin quyền sớm, disclosure sai	Purpose, minimization, just-in-time permission
7. Supply chain	SDK không owner, dependency cũ, build không kiểm soát	Inventory, scanning, review, provenance
8. Platform interaction	Deep link, WebView, exported component, pasteboard	Allowlist, auth gate, platform hardening
9. Integrity/anti-abuse	Fake client, tampering, automation	Server controls, attestation signal, rate/risk engine
10. Crypto/input/error	Tự chế crypto, validate ở client, lỗi lộ chi tiết	Standard primitives, server validation, safe error

1. Secret, API key và token

Không có secret thực sự bí mật trong binary được phân phối tới người dùng. Obfuscation có thể tăng công sức phân tích nhưng không biến API key thành bí mật. Key có quyền truy cập dữ liệu hoặc tạo chi phí nên nằm ở backend/secrets manager.

• Tách public identifier khỏi credential có quyền.
• Giới hạn scope, quota, package/bundle hoặc endpoint khi vendor hỗ trợ.
• Access token ngắn hạn; refresh/revoke phù hợp với use case.
• Không ghi token, OTP, password hoặc secret vào analytics/crash log.
• Có inventory và quy trình rotate khi lộ hoặc nhân sự thay đổi.

2. Dữ liệu cục bộ và backup

Trước khi mã hóa, hãy hỏi dữ liệu có cần nằm trên thiết bị hay không. Dữ liệu không lưu sẽ không bị trích xuất từ local storage. Với dữ liệu cần lưu, chọn cơ chế theo loại dữ liệu và threat model.

Loại	Hướng xử lý
Credential/token	Keychain/Keystore và session lifecycle
Cache nội dung	TTL, xóa khi logout và không chứa dữ liệu vượt nhu cầu
File nhạy cảm	App-private storage, encryption khi cần, chống backup ngoài ý muốn
Ảnh/chứng từ	Không lưu vào thư viện chung nếu không cần; xóa file tạm
Log	Redaction, retention và quyền truy cập
Screenshot/app switcher	Che màn hình nhạy cảm theo risk, không áp dụng máy móc mọi màn hình

Test cần kiểm tra dữ liệu sau logout, uninstall/restore, backup, crash, background và khi thiết bị bị mất. Không nên tuyên bố “mã hóa toàn bộ” nếu key nằm cùng nơi và không có lifecycle.

3. Giao tiếp mạng và endpoint

• Dùng TLS và không bỏ qua lỗi certificate trong production.
• Tách development, staging và production bằng build configuration an toàn.
• Không để debug proxy, test credential hoặc endpoint nội bộ trong release.
• Thiết kế timeout, retry và idempotency cho request quan trọng.
• Chống replay tại luồng cần bảo vệ bằng nonce/timestamp/idempotency theo kiến trúc.

Certificate pinning có thể giảm một số rủi ro nhưng làm tăng rủi ro vận hành nếu rotate certificate sai hoặc app cũ không còn kết nối. Chỉ áp dụng khi threat model biện minh, có backup pin/rotation và cách xử lý sự cố.

4. Authentication, session và account recovery

Đăng nhập an toàn không chỉ là yêu cầu mật khẩu mạnh. Attack surface còn gồm OTP, social login, refresh token, logout, đổi số điện thoại, quên mật khẩu, thiết bị mới và support-assisted recovery.

• Không tiết lộ tài khoản tồn tại qua message hoặc timing dễ khai thác.
• Rate limit, anti-automation và risk signal cho login/OTP/recovery.
• Step-up authentication trước thao tác nhạy cảm khi phù hợp.
• Revoke session khi đổi mật khẩu, mất thiết bị hoặc phát hiện compromise.
• Biometric chỉ mở khóa credential/capability đã thiết kế; không coi biometric UI là authorization backend.

5. Authorization phải nằm ở server

Ẩn nút hoặc màn hình không ngăn người dùng gọi API trực tiếp. Backend phải kiểm tra người gọi có quyền thực hiện action trên object cụ thể hay không, ở trạng thái và tenant phù hợp hay không.

• Test object ID của người dùng khác, tenant khác và role khác.
• Không tin giá, điểm, trạng thái, owner hoặc permission do client gửi.
• Enforce business invariant cho coupon, balance, inventory và workflow.
• Có audit trail cho thao tác quyền cao và thay đổi dữ liệu quan trọng.
• Dùng deny-by-default và least privilege cho admin/service account.

6. Privacy, permission và dữ liệu SDK

Permission của hệ điều hành chỉ là một lớp. Doanh nghiệp vẫn cần mục đích xử lý, disclosure, retention và control với dữ liệu được thu qua SDK hoặc backend.

• Xin quyền đúng lúc người dùng thực hiện tính năng liên quan.
• Cho phép luồng thay thế khi người dùng từ chối nếu nghiệp vụ cho phép.
• Đối chiếu behavior thật với App Privacy/Data safety và privacy policy.
• Kiểm kê dữ liệu SDK thu, chia sẻ và chuyển ra ngoài hệ thống.
• Không dùng device identifier hoặc location vượt mục đích đã thông báo.
• Có workflow export, correction, deletion và account deletion theo phạm vi áp dụng.

7. SDK, dependency và build supply chain

Control	Câu hỏi
Inventory	Đang dùng SDK/dependency nào, version và owner là ai?
Approval	SDK mới được review về dữ liệu, quyền, license và vendor chưa?
Scanning	Có cảnh báo vulnerability và quy trình triage không?
Locking	Build có khóa version và kiểm soát nguồn package?
CI/CD	Runner, secret, artifact và release permission được bảo vệ?
Signing	Signing key/certificate thuộc doanh nghiệp và có access control?
Removal	SDK không còn dùng đã được xóa khỏi binary và disclosure?

NIST Secure Software Development Framework nhấn mạnh việc chuẩn bị tổ chức, bảo vệ phần mềm, tạo phần mềm an toàn và phản ứng với vulnerability như các nhóm thực hành xuyên vòng đời. Có thể dùng NIST SSDF SP 800-218 để rà soát quy trình phát triển, không chỉ code mobile.

8. Deep link, WebView và platform interaction

• Deep link không được bỏ qua authentication/authorization.
• Validate scheme, host, path và parameter; không mở URL tùy ý.
• WebView dùng allowlist, hạn chế bridge và không render nội dung không tin cậy với quyền cao.
• Review Android exported component, intent filter và content provider.
• Review iOS URL scheme/universal link, pasteboard, file sharing và entitlement.
• Không để notification hoặc app switcher lộ dữ liệu nhạy cảm ngoài ngữ cảnh.

9. App integrity và anti-abuse

App Attest cho phép server có thêm tín hiệu rằng request liên quan đến instance app hợp lệ; Play Integrity giúp đánh giá request/action có đến từ app chính hãng và môi trường đáp ứng các verdict liên quan hay không. Đây là tín hiệu risk, không phải bằng chứng tuyệt đối và không thay thế authentication, authorization hoặc business controls.

Apple mô tả App Attest như cách app khẳng định tính hợp lệ để server tự tin hơn khi cấp quyền truy cập tài nguyên nhạy cảm. Google yêu cầu việc giải mã/xác minh token integrity được thực hiện trong môi trường server an toàn, không để key ở client. Tham khảo Apple DeviceCheck/App Attest và Play Integrity API.

• Áp dụng cho action rủi ro thay vì chặn toàn bộ app theo một verdict duy nhất.
• Thiết kế response theo risk: allow, step-up, limit, review hoặc deny.
• Có fallback cho lỗi dịch vụ, thiết bị hợp lệ nhưng không hỗ trợ hoặc network failure.
• Không đặt bí mật xác minh hoặc logic quyết định hoàn toàn ở client.
• Đo false positive và tác động tới người dùng hợp lệ.

10. Cryptography, validation và error handling

• Không tự thiết kế thuật toán hoặc protocol mã hóa.
• Quản lý key tách khỏi dữ liệu, có rotation/revocation khi cần.
• Validate input, authorization và invariant tại server.
• Encode output theo context, đặc biệt khi dùng WebView/HTML.
• Error trả cho client không lộ stack trace, SQL, secret hoặc dữ liệu nội bộ.
• Log server giữ correlation ID và evidence cần thiết nhưng redaction dữ liệu nhạy cảm.

Chiến lược kiểm chứng bảo mật

Lớp test	Mục tiêu	Thời điểm
Requirement/threat review	Phát hiện thiếu control trước khi code	Discovery/refinement
Code/config review	Secret, platform config, authorization và unsafe pattern	Mỗi thay đổi rủi ro
SAST/dependency/secret scan	Tìm pattern và vulnerability đã biết	CI và định kỳ
DAST/API test	Kiểm tra endpoint, object/action auth và abuse	Staging/test
Mobile dynamic test	Storage, network, platform, runtime và tamper	Build gần production
Penetration test	Kiểm tra chuỗi khai thác theo phạm vi/rủi ro	Trước launch lớn hoặc định kỳ
Production monitoring	Phát hiện abuse, incident và regression	Liên tục

Không công cụ nào thay thế toàn bộ manual review. Scanner có thể phát hiện dependency hoặc pattern; authorization, business logic, privacy và abuse thường cần test theo ngữ cảnh.

Security release gate

• Data inventory, threat model và security owner được cập nhật.
• Không có secret nhạy cảm trong source, artifact, config và log.
• Authentication, recovery, token lifecycle và logout đã test.
• Authorization/API negative tests pass cho role, object và tenant.
• Storage, backup, screenshot, notification và log đã review.
• Deep link, WebView, exported component và production config đã test.
• SDK/dependency inventory và vulnerability triage hoàn tất.
• App Privacy/Data safety, permission copy và behavior thật nhất quán.
• High-risk finding đã fix hoặc có risk acceptance được người có thẩm quyền phê duyệt.
• Monitoring, incident contact, rollback/hotfix và backup/restore sẵn sàng.

Beta iOS/Android có thể dùng TestFlight và Google Play testing tracks để kiểm tra build gần production. Beta testing không thay penetration test hoặc backend security test.

Lộ trình remediation theo risk gate

Không nên ép mọi app vào lịch 30–60–90 ngày. Thời gian phụ thuộc số hệ thống, severity, khả năng release và dependency. Có thể dùng các cổng sau:

Cổng	Đầu ra	Điều kiện qua
Inventory	Data, asset, SDK, endpoint và owner	Không còn vùng không có chủ
Risk baseline	Threat model, findings và severity	Rủi ro cao được xác định
Contain	Rotate secret, revoke access, disable flow hoặc limit	Giảm phơi nhiễm khẩn cấp
Remediate	Fix, test và migration	Evidence đáp ứng acceptance
Verify	Retest và regression	Finding đóng hoặc risk accepted
Institutionalize	CI checks, checklist, training và monitoring	Control được lặp lại trong SDLC

Bảo mật sau release

• Theo dõi account takeover, abuse, fraud, error và hành vi API bất thường.
• Patch dependency theo risk và exposure, không chỉ theo lịch.
• Review quyền production, service account, store và cloud định kỳ.
• Diễn tập incident, revoke token/key, backup/restore và communication.
• Có kênh tiếp nhận vulnerability và quy trình triage/reporting.
• Gắn security backlog với kế hoạch bảo trì app sau bàn giao.

Khi nào cần đánh giá chuyên sâu?

• App xử lý thanh toán, số dư, điểm có giá trị hoặc giao dịch quan trọng.
• Có PII/sinh trắc học/sức khỏe/tài chính hoặc dữ liệu trẻ em.
• Có nhiều role, tenant, admin hoặc integration doanh nghiệp.
• Release thay đổi authentication, payment, data flow hoặc kiến trúc.
• Đã xảy ra incident, credential leak hoặc suspicious activity.
• Khách hàng, đối tác, hợp đồng hoặc quy định yêu cầu bằng chứng độc lập.

Với app dùng AI, cần bổ sung data flow, prompt/output logging, vendor retention, access và abuse control; xem thêm tích hợp AI vào app hiện tại.

Câu hỏi dành cho đội phát triển

• Dữ liệu và trust boundary đã được mô tả chưa?
• Control nào nằm ở mobile, backend, cloud và operations?
• MASVS controls nào nằm trong phạm vi và test evidence ở đâu?
• Authorization API được test bằng negative case thế nào?
• Ai sở hữu signing key, store, cloud, secret và vulnerability backlog?
• Quy trình patch, incident, hotfix và disclosure sau bàn giao ra sao?
• Có chấp nhận đánh giá độc lập và retest finding không?

Các câu hỏi này nên nằm trong discovery, SOW và Definition of Done của dự án phát triển ứng dụng di động, không chỉ được hỏi trước ngày release.

Câu hỏi thường gặp

App nhỏ có cần security test không?

Có. Phạm vi có thể nhỏ hơn, nhưng secret, storage, authentication, authorization, permission, dependency và production config vẫn cần kiểm tra theo rủi ro.

Mã hóa có đủ để bảo vệ app không?

Không. Mã hóa không sửa được authorization sai, token bị lộ, recovery yếu, SDK thu dữ liệu thừa hoặc quy trình release thiếu kiểm soát.

App Attest và Play Integrity có chặn được app giả hoàn toàn?

Không nên coi đây là bảo đảm tuyệt đối. Chúng cung cấp tín hiệu integrity/risk để backend quyết định phù hợp. Server vẫn phải xác thực, phân quyền, rate limit và bảo vệ business rule.

Pentest một lần trước launch có đủ không?

Không. Pentest là ảnh chụp theo phạm vi và thời điểm. App, dependency, API và threat thay đổi nên cần secure SDLC, monitoring, patch và retest sau thay đổi quan trọng.

Kết luận

App an toàn không phải app được gắn nhiều cơ chế nhất, mà là app có threat model rõ, control đúng nơi, test evidence, owner và khả năng phản ứng khi giả định thay đổi. Hãy bảo vệ server-side authorization và dữ liệu trước, dùng platform/integrity controls theo risk, rồi đưa security vào release và bảo trì như một quy trình lặp lại.