Bảo mật ứng dụng di động là bảo vệ tài khoản, dữ liệu khách hàng và giao dịch quan trọng. Doanh nghiệp cần kiểm tra cả điện thoại lẫn hệ thống máy chủ, vì yêu cầu gửi từ app có thể bị người khác sửa đổi.
Không có app nào “an toàn tuyệt đối”. Mục tiêu thực tế là chặn người truy cập sai quyền, giảm nguy cơ lộ dữ liệu, phát hiện và xử lý sự cố từ giai đoạn thiết kế đến vận hành.
Trả lời nhanh: Hãy kiểm tra dữ liệu và quyền truy cập; đăng nhập; thông tin trên điện thoại; thư viện bên thứ ba; kiểm thử, sao lưu và xử lý sự cố. Trước khi ra mắt phải có người duyệt kết quả và chịu trách nhiệm các lỗi còn lại.
App cần bảo vệ những gì của doanh nghiệp và khách hàng?
| Phần cần bảo vệ | Ví dụ rủi ro | Điều phải yêu cầu kiểm tra |
|---|---|---|
| Thông tin khách hàng | Lộ số điện thoại, hồ sơ qua nhật ký lỗi hoặc đơn vị bên ngoài. | Thu đúng dữ liệu cần thiết, giới hạn quyền, kiểm tra lưu/xóa. |
| Tài khoản | Người mất điện thoại vẫn bị dùng tài khoản; kẻ khác chiếm phiên. | Đăng nhập phù hợp, đăng xuất các thiết bị, thu hồi phiên. |
| Đơn hàng, thanh toán, API | Khách xem đơn người khác hoặc tự sửa số tiền. | Máy chủ kiểm tra quyền, giá, trạng thái và thao tác bất thường. |
| Dữ liệu trên điện thoại | Lộ mã đăng nhập, file tạm, nội dung trên màn hình khóa. | Lưu an toàn, xóa dữ liệu khi cần, không lộ bí mật. |
| Thư viện và bản phát hành | Mã từ bên thứ ba lỗi thời, lộ khóa phát hành. | Kiểm kê thư viện, quản lý quyền và khóa, rà trước khi đưa lên kho. |
| Vận hành | Không biết app đang bị khai thác hay không thể phục hồi. | Cảnh báo, sao lưu/khôi phục và quy trình xử lý sự cố. |
Ở Việt Nam, Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15 và Nghị định 356/2025/NĐ-CP có hiệu lực từ 01/01/2026. Doanh nghiệp phải rà việc thu thập, sử dụng, chia sẻ, lưu giữ, xóa dữ liệu và quyền của khách theo trường hợp thực tế. Về kỹ thuật, OWASP MASVS là bộ tiêu chí tham khảo cho bảo mật ứng dụng di động, không thay thế đánh giá pháp lý, kiểm thử máy chủ hoặc chứng nhận an toàn.
Bước 1: Biết app thu dữ liệu gì và nguy cơ nằm ở đâu
Liệt kê app thu dữ liệu gì, lưu ở đâu, chia sẻ cho ai và trong bao lâu. Đội kỹ thuật cần vẽ đường đi dữ liệu và đánh giá nguy cơ (threat model) cho những thao tác có thể gây thiệt hại như chuyển tiền, sửa quyền hoặc xuất danh sách khách.
| Câu hỏi cần hỏi bên làm app | Tài liệu/bằng chứng nên nhận |
|---|---|
| Thu dữ liệu gì, dùng để làm gì? | Danh sách dữ liệu, vị trí lưu, người nhận, thời gian lưu. |
| Dữ liệu đi qua bên nào? | Sơ đồ điện thoại → máy chủ → bên tích hợp; nơi cần kiểm soát quyền. |
| Việc nào cần bảo vệ nhất? | Danh sách giao dịch, xuất dữ liệu, đổi quyền, tài khoản quản trị. |
| Có nguy cơ bị giả mạo gì? | Kịch bản sửa thông tin đơn, dùng tài khoản người khác, gửi lại giao dịch. |
| Ai xử lý khi phát hiện vấn đề? | Người phụ trách, mức rủi ro, thời hạn khắc phục, kết quả thử lại. |
Ví dụ giả định: một khách đăng nhập rồi thử truy cập mã đơn hàng của người khác. Hệ thống phải từ chối, kể cả khi người đó sửa yêu cầu gửi lên máy chủ. Đây là kịch bản kiểm tra có giá trị hơn một sơ đồ kỹ thuật dài mà không ai chịu trách nhiệm.
Bước 2: Kiểm tra quyền ở máy chủ, không chỉ trên app
Ẩn nút không phải phân quyền. Với mỗi yêu cầu, máy chủ phải kiểm tra đúng người, đúng đơn, đúng vai trò và trạng thái, không tin giá tiền hay quyền quản trị do điện thoại gửi. Xem lỗ hổng kiểm tra quyền theo đối tượng của OWASP.
Phải thử đăng nhập, OTP, quên mật khẩu, đổi thiết bị và đăng xuất. Với việc nhạy cảm cần xác minh thêm; nếu bị nghi xâm nhập, hệ thống phải thu hồi phiên và mã truy cập.
Phân quyền theo vai trò (RBAC) cho biết nhân viên hoặc quản lý được làm gì, nhưng vẫn phải kiểm tra họ được thao tác trên hồ sơ nào. Xác thực nhiều yếu tố (MFA) giúp bảo vệ tài khoản, không thay cho phân quyền. Xem thêm hướng dẫn phân quyền RBAC và MFA là gì.
Bước 3: Hạn chế dữ liệu nhạy cảm lưu trên điện thoại
Chỉ lưu trên điện thoại dữ liệu thật sự cần. Mã đăng nhập và dữ liệu tạm phải được bảo vệ, xóa đúng thời điểm. Kiểm tra cả file tải xuống, màn hình khóa, bộ nhớ tạm, sao lưu và nhật ký lỗi vì những nơi này có thể làm lộ thông tin.
Không đưa khóa quản trị, mật khẩu hệ thống hoặc khóa truy cập nhiều khách vào bản app phát hành; người khác có thể phân tích tệp cài đặt. Khóa quan trọng phải ở máy chủ, giới hạn quyền và thu hồi được khi bị lộ.
Bước 4: Bảo vệ kết nối và các đường dẫn mở app
Ứng dụng phải dùng kết nối mã hóa (HTTPS/TLS), không bỏ qua lỗi chứng chỉ. Phiên bản công khai không được mang theo tài khoản thử, khóa bí mật hoặc địa chỉ máy chủ thử nghiệm. Những thao tác như thanh toán cần được máy chủ kiểm tra và có biện pháp tránh xử lý trùng khi mất mạng hoặc khách gửi lại.
Khi khách nhấn đường dẫn mở thẳng đơn hàng trong app (deep link), hệ thống vẫn phải kiểm tra đăng nhập và quyền xem đơn. Nếu app mở một trang web bên trong (WebView), chỉ cho tải nguồn tin cậy; không cấp quyền nguy hiểm cho nội dung chưa được kiểm tra.
Bước 5: Kiểm tra phần mềm bên thứ ba và bản phát hành
Các thư viện hoặc bộ công cụ gắn thêm vào app (SDK) có thể thu thập dữ liệu hoặc làm phát sinh lỗ hổng. Hãy yêu cầu đội phát triển liệt kê thành phần đang dùng, phiên bản, dữ liệu chia sẻ, người quản lý và kế hoạch cập nhật. Mã nguồn, quy trình tạo bản cài, tài khoản phát hành và khóa ký ứng dụng cần được kiểm soát, phân quyền và bàn giao theo hợp đồng.
Theo NIST SSDF, bảo mật cần được đưa vào quy trình làm phần mềm, từ thiết kế, lập trình, kiểm tra đến sửa lỗi. Một lần thuê kiểm thử xâm nhập (pentest) trước ngày ra mắt không đủ để thay thế những công việc này.
App Attest và Play Integrity có thay được phân quyền không?
Apple App Attest và Google Play Integrity bổ sung dấu hiệu về ứng dụng hoặc thiết bị. Chúng không thay việc đăng nhập, phân quyền và xác minh giao dịch ở máy chủ; phải tránh chặn nhầm khách hợp lệ.
Biện pháp hạn chế sửa ứng dụng, nhận diện thiết bị đã can thiệp hoặc làm khó việc phân tích mã nguồn có thể hữu ích với chức năng rủi ro cao. Không nên mua thêm các tính năng này chỉ vì quảng cáo “chống hack tuyệt đối”; phải dựa trên kịch bản rủi ro thực tế.
Checklist bảo mật: Khi nào chưa nên phát hành app?
| Nhóm cần kiểm tra | Điều kiện trước khi ra mắt |
|---|---|
| Thông tin cá nhân | Đã rà dữ liệu thu/lưu/chia sẻ, quyền truy cập và nội dung thông báo cho khách? |
| Tài khoản và phân quyền | Đã thử đăng nhập, khôi phục tài khoản, thu hồi phiên và chặn xem dữ liệu người khác? |
| Ứng dụng và kết nối | Không để lộ khóa bí mật, dữ liệu nhạy cảm, hệ thống thử hoặc lỗi kết nối nghiêm trọng? |
| Mã nguồn và phát hành | Thư viện và khóa phát hành được quản lý, có người kiểm tra và phê duyệt? |
| Kết quả kiểm thử | Có danh sách lỗi, mức ảnh hưởng, bằng chứng thử lại và người chấp nhận rủi ro? |
| Vận hành và khôi phục | Có cảnh báo, sao lưu đã thử khôi phục, liên hệ sự cố và phương án sửa khẩn cấp? |
Không phát hành khi còn lỗi nghiêm trọng có thể gây lộ dữ liệu, vượt quyền hoặc sai giao dịch mà chưa kiểm soát được. Ngoại lệ phải có người được quyền phê duyệt, lý do và thời hạn xử lý.
Kiểm thử gì và làm gì sau khi phát hành?
Kiểm thử phải bao gồm mã nguồn, quyền truy cập API, dữ liệu trên điện thoại, giao dịch và tình huống mất mạng. Với rủi ro cao có thể cần kiểm thử xâm nhập. Đơn vị thực hiện phải bàn giao phạm vi đã thử, lỗi, mức ảnh hưởng và bằng chứng đã thử lại sau sửa; một lần kiểm thử không bảo đảm an toàn mãi mãi.
Sau khi phát hành, tiếp tục theo dõi đăng nhập lạ, yêu cầu API bất thường, lỗi, thư viện lỗi thời và cảnh báo từ đối tác. Khi có sự cố, cần hạn chế tác động, thu hồi quyền/khóa có nguy cơ, lưu bằng chứng, khôi phục và thông báo đúng bên theo nghĩa vụ áp dụng. Kết hợp với quy trình vận hành bảo mật hệ thống để không bỏ trống trách nhiệm.
Câu hỏi thường gặp
App nhỏ có cần kiểm tra bảo mật không?
Có. Dù chỉ có vài trăm khách, app vẫn có tài khoản, dữ liệu và kết nối máy chủ. Hãy ưu tiên kiểm tra phân quyền, mật khẩu/khóa bí mật, thông tin lưu trên điện thoại và người xử lý khi có sự cố.
Mã hóa có đủ để bảo vệ dữ liệu khách hàng?
Không. Mã hóa giúp bảo vệ dữ liệu nhưng không ngăn được lỗi cấp nhầm quyền, tài khoản bị chiếm hoặc lưu thông tin quá mức. Cần kiểm soát cả người truy cập, cách dùng dữ liệu và hoạt động sau phát hành.
Kết luận
Chủ doanh nghiệp không cần tự kiểm tra mã nguồn nhưng nên yêu cầu danh sách dữ liệu, quyền truy cập, kịch bản kiểm thử, bằng chứng sửa lỗi và kế hoạch xử lý sự cố. Khi cập nhật tính năng hoặc đổi nhà cung cấp, cần đánh giá lại những phần bị ảnh hưởng.
Nguồn tham khảo
- OWASP Mobile Application Security Verification Standard
- NIST SP 800-218: Secure Software Development Framework
- Android Developers: Play Integrity API
- Apple Developer: Validating apps that connect to your server
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.