Tôi không viết code, nhưng tôi thấy cái giá của việc bỏ qua security
10/06/2026
16
views
0
#4 on leaderboard of challenge:
Khi làm QA/Tester, có một thời gian tôi từng nghĩ: chỉ cần một tính năng hoạt động đúng theo yêu cầu thì đó đã là một sản phẩm tốt.
Một màn hình hiển thị đúng, một nút bấm hoạt động đúng, dữ liệu trả về đúng kết quả — mọi thứ đều có vẻ ổn.
Nhưng càng tham gia nhiều dự án, tôi càng nhận ra có những vấn đề không nằm ở việc “tính năng có chạy hay không”, mà nằm ở câu hỏi: “Nếu người dùng sử dụng sai cách thì chuyện gì sẽ xảy ra?”
Đây cũng là lúc tôi nhìn vấn đề security khác đi.
Trong quá trình test một hệ thống, tôi từng gặp một tình huống khiến tôi thay đổi cách suy nghĩ. Một chức năng về mặt giao diện hoạt động hoàn toàn bình thường. User không có quyền xem dữ liệu của người khác trên màn hình.
Nhưng khi kiểm tra sâu hơn ở phía API, tôi phát hiện nếu thay đổi một vài thông tin trong request, hệ thống vẫn có thể trả về dữ liệu không thuộc quyền truy cập.
Về mặt chức năng, tính năng vẫn có thể được xem là “pass”.
Nhưng về mặt bảo mật, đó là một rủi ro.
Nếu chỉ test theo luồng thông thường:
- đăng nhập
- thao tác đúng
- kiểm tra kết quả hiển thị
thì có thể sẽ bỏ qua những trường hợp quan trọng như:
- User có thể truy cập dữ liệu của người khác không?
- API có kiểm tra quyền thật sự không?
- Dữ liệu nhạy cảm có bị trả về quá nhiều không?
- Người dùng có thể cố tình thay đổi request để vượt qua giới hạn không?
Từ đó, cách test của tôi thay đổi.
Tôi không chỉ kiểm tra “happy case” nữa, mà bắt đầu suy nghĩ theo hướng của một người dùng muốn làm sai:
“Nếu tôi cố tình đổi ID thì sao?”
“Nếu tôi gọi API trực tiếp thì sao?”
“Nếu tài khoản này thử truy cập dữ liệu của tài khoản khác thì sao?”
“Nếu tôi gọi API trực tiếp thì sao?”
“Nếu tài khoản này thử truy cập dữ liệu của tài khoản khác thì sao?”
Tôi cũng nhận ra một điều: security không nên là việc để đến cuối cùng mới xử lý.
Tất nhiên, trong thực tế, các team luôn có áp lực về thời gian. Đặc biệt với những sản phẩm cần ra mắt nhanh, việc cân bằng giữa tốc độ và an toàn không hề đơn giản.
Theo tôi, không nhất thiết phải xây dựng mọi thứ quá phức tạp ngay từ đầu. Cách hiệu quả hơn là xác định đâu là phần quan trọng cần bảo vệ trước:
- Dữ liệu cá nhân của người dùng.
- Quyền truy cập giữa các nhóm tài khoản.
- Các API quan trọng.
- Những luồng liên quan đến thanh toán hoặc thông tin nhạy cảm.
Những phần này cần được đặt security ngay từ đầu, thay vì chờ đến khi sản phẩm lớn lên mới sửa.
Trước đây tôi từng nghĩ security là phần việc chủ yếu của Developer. Nhưng sau quá trình làm việc, tôi thấy đây là trách nhiệm của cả team.
Dev xây dựng hệ thống.
QA tìm ra những góc nhìn khác.
Product hiểu người dùng.
Mỗi vị trí đều góp phần tạo nên một sản phẩm đáng tin cậy.
QA tìm ra những góc nhìn khác.
Product hiểu người dùng.
Mỗi vị trí đều góp phần tạo nên một sản phẩm đáng tin cậy.
Vibe coding hay phát triển nhanh giúp chúng ta kiểm chứng ý tưởng sớm hơn. Nhưng nếu chỉ tập trung vào tốc độ mà bỏ qua an toàn, cái giá phải trả sau này có thể lớn hơn rất nhiều.
Bài học tôi rút ra là:
Một sản phẩm tốt không chỉ là sản phẩm chạy được, mà còn là sản phẩm có thể bảo vệ người dùng khi mọi thứ không diễn ra như mong đợi.
Build nhanh giúp sản phẩm đi trước.
Security giúp sản phẩm đi xa.
Security giúp sản phẩm đi xa.