.env và những hệ lụy khi sử dụng

.env và những hệ lụy khi sử dụng

Những mẩu tin ngắn hàng ngày dành cho bạn
  • Hẳn là nhiều người ở đây đã nghe đến kiểu tấn công bảo mật Clickjacking rồi nhỉ. Kẻ tấn công thường nhúng một website (thường là mục tiêu) vào trong một iframe trên website của chúng, sau đó làm mờ hoặc ẩn nó đi rồi đặt vào vị trí các nút bấm trên web, ví dụ "Bấm vào để nhận quà". Đâu ai ngờ rằng phía trên nút bấm đó là một nút bấm khác trong iframe. Khá nguy hiểm!

    Nhưng trình duyệt đã có cách ngăn chặn kiểu tấn công này bằng các quy tắc như tiêu đề X-Frame-Options, frame-ancestors của CSP và SameSite: Lax/Strict của Cookies...

    Mới đây, đã xuất hiện thêm kiểu tấn công mới - "DoubleClickjacking" 😨. Đại ý là "hắn" lợi dụng hành động double click để lừa người dùng bấm vào một nút mà hắn muốn. Chi tiết hơn trong bài viết này: DoubleClickjacking: A New Era of UI Redressing.

    » Xem thêm
  • Mọi người đã nghe nói đến Jujutsu - jj - một dạng quản lý phiên bản cho mã nguồn (version control system) chưa? Có vẻ như nó đang nhận được nhiều sự quan tâm.

    Chờ xíu! Chẳng phải git đã quá tốt rồi sao? Thế thì chế ra thằng jj để làm gì nữa? Cũng hơi khó trả lời nhỉ? Mỗi công cụ sinh ra chắc chắn phải cải thiện hoặc khắc phục được nhược điểm của cái trước. Cho nên jj ắt hẳn phải làm được điều gì đó mà git chưa làm được nên mới nổi lên như vậy.

    Thật ra mình đã nghe nói đến jj từ vài tháng trước rồi, nhưng vào đọc thì toàn kiến thức cao siêu. Hoặc là đang mang nặng cái lối suy nghĩ của git vào trong đầu rồi nên chưa lĩnh hội ra được điều gì cả.

    Mình hay có kiểu cái gì đọc lần 1 mà không hiểu thì đọc tiếp lần 2, lần 2 không hiểu thì đọc tiếp lần 3... đến lần thứ n mà vẫn không hiểu thì bỏ. Cơ mà không phải là từ bỏ mà một thời gian sau đó quay lại đọc tiếp. Đến một lúc nào đó khả năng mình sẽ hiểu ra một ít vấn đề, thế mới tài 😆.

    Thì cái jj này có vẻ như nó đang mở ra được tính linh hoạt trong việc "cam kết" mã. Tưởng tượng bạn đang làm việc trên một dự án, đang ở nhánh này, muốn sang nhánh khác để sửa, nhưng mà lại đang viết dở ở nhánh này, thế là phải stash, rồi checkout, rồi commit, rồi merge hoặc rebase lại vào nhánh cũ... nhìn chung quá trình làm việc với git nghiêm ngặt đến mức cứng nhắc, cần nhiều thao tác để giải quyết một vấn đề, chưa kể cái cây commit (commit-tree) nữa thì ôi thôi, khỏi xem cho đỡ nhức mắt. Thế nên ông jj này đang làm cách nào đó để bạn khỏi cần phải quan tâm đến các nhánh luôn, sửa trực tiếp vào commit. Nghe ảo nhỉ 😂.

    Đấy mới lĩnh hội được đến đấy, hy vọng sau n lần đọc lại nữa mình sẽ viết được một bài chi tiết hơn về công cụ này.

    » Xem thêm
  • Gòi gòi tới công chiện gòi 🤤🤤🤤

    » Xem thêm

Vấn đề

Có một lời khuyên là cấu hình nào có thể thay đổi tùy theo môi trường triển khai (deploy) thì nên đưa nó ra thành biến môi trường (Os Environment). Như vậy thì thông thường, chúng ta sẽ có một file .env để lưu trữ lại những biến đó, .env thường được nằm trong .gitignore và nó chỉ được tạo ra khi triển khai ứng dụng lên môi trường Internet hoặc khởi chạy trên máy local. Một tệp .env có thể trông giống như sau:

DB_HOST=localhost
DB_PORT=5432
DB_USER=postgres
DB_PASSWORD=password
...

Sau này, chúng ta cần .env linh hoạt hơn, có thể thay đổi tùy theo một biến môi trường truyền vào. Ví dụ như nó có thể thay đổi thông qua biến NODE_ENV. Lúc đó ta lại có .env.local, .env.development, .env.production... Mà khi khởi chạy, chỉ cần NODE_ENV=local node index.js thì .env.local sẽ tự động được sử dụng.

Một giải pháp khác so với cách dùng .env là lưu trữ lại cấu hình trong bất kì một tệp nào như là JavaScript, JSON, yml... cách dùng nó cũng tương tự như .env, có điều nó cho phép các cấu hình lồng nhau để dễ dàng phân vùng cấu hình một cách rõ ràng hơn. Nhưng chung quy lại, cả 2 vẫn là tạo ra các tệp lưu trữ biến môi trường.

Hiện tại, tôi vẫn đang sử dụng .env trong một số dự án mình tham gia, không thể phủ nhận được sự tiện lợi của .env. Tuy nhiên .env không phải là không có bất cập.

Đầu tiên là tính bảo mật. Các tệp .env không khác gì một file văn bản không mã hóa, vì thế bất kì ai cũng có thể đọc nó. Thậm chí mọi người thường hay sao chép hoặc gửi trực tiếp .env cho nhau thông qua một ứng dụng nhắn tin nào đó, khiến nội dung có thể bị lộ hoặc cố ý đẩy ra bên ngoài.

Các tệp .env không có phân quyền, nghĩa là bất kì ai cũng có thể truy cập vào được nếu xin phép, điều đó cũng vô tình tiết lộ tất cả nội dụng của tất cả các biến. Ví dụ, một bạn developer xin quyền khởi động project ở dưới máy local trỏ vào môi trường stagging, có thể chúng ta phải gửi toàn bộ nội dung .env ở môi trường stagging cho bạn ấy.

Vì .env là bí mật nên nó thường không được commit vào git. Nghĩa là lịch sử thay đổi các biến trong .env sẽ rất khó để có thể theo dõi thông qua công cụ này được. Hầu hết cách làm của chúng ta sẽ thêm một tệp gì đó như là .env.example để lưu lại những giá trị có thể có trong .env. Tuy nhiên cách làm này chỉ để biết được .env có gì chứ không quản lý được nội dung của .env. Nhiều lúc thêm một biến mới nhưng lại quên cập nhật trong các tệp môi trường khác lại khiến ứng dụng bị lỗi.

Thật tệ hại nếu như chúng ta lỡ tay commit .env vào trong dự án, hoặc quên mất trong .dockerignore... Đây là sai sót có yếu tố con người tuy nhiên lại là một trong những vấn đề gây ra rò rỉ thông tin bảo mật nếu không phát hiện sớm.

Vậy chúng ta có giải pháp nào tốt hơn không?

Giải pháp thay thế .env truyền thống

Với những khuyến điểm tồn tại như ở trên, dĩ nhiên chúng ta sẽ có nhiều giải pháp thay thế để quản lý được các biến môi trường một cách hiệu quả hơn. Một trong số đó có thể kể đến như Azure Secrets Manager hay Vault. Tuy nhiên, các công cụ đó có vẻ phù hợp với cấu hình phức tạp và mở rộng hơn sau này. Nếu bạn cần một công cụ đơn giản hơn, chỉ đơn giản tập trung vào quản lý các biến bảo mật thì Infisical là một giải pháp dễ dàng mà tiết kiệm hơn nhiều.

Infisical là một giải pháp mã hóa đầu cuối mã nguồn mở, có thể sử dụng để đồng bộ hóa các biến môi trường trong nhóm và cơ sở hạ tầng. Bằng cách sử dụng Infisical, chúng ta có thể giải quyết được hầu hết các vấn đề nêu ra ở đầu bài viết.

Mã nguồn của Infisical có thể được tìm thấy tại Infisical Github, chúng ta có thể tự triển khai một máy chủ cho riêng mình bằng nhiều cách như sử dụng Docker, AWS, DigitalOcean... Hoặc nếu không, Infisical cung cấp dịch vụ Cloud hoàn toàn miễn phí với một số giới hạn. Bạn đọc quan tâm có thể đăng kí tại Infisical Signup.

Infisical

Infisical hỗ trợ rất nhiều dịch vụ Cloud như AWS, Vercel, Netlify... hoặc các Framework/Library như React, Vue, SvelteKit...

Ví dụ sử dụng trong Node: Sau khi thêm các biến môi trường vào Infisical, bạn có thể khởi động dự án Node.js bằng cách:

$ infisical init
$ infisical run -- npm start

Lúc này các biến môi trường sẽ được truyền vào trong ứng dụng Node.

Để xem đầy đủ các cách tích hợp cũng như sử dụng trong các Project khác, bạn đọc có thể xem tại Infisical Integrations.

Tổng kết

.env là một trong những cách giúp chúng ta quản lý biến môi trường trong triển khai ứng dụng lên nhiều môi trường khác nhau. Tuy nhiên, cách tiếp cận thông qua .env có phần lỗi thời và gây ra nhiều vấn đề cần phải được giải quyết. Infisical có thể được coi là một giải pháp đơn giản mà hiệu quả hơn so với Vault hay Azure Secrets Manager.

Cao cấp
Hello

Bí mật ngăn xếp của Blog

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (1)

Nội dung bình luận...
Avatar
Ẩn danh1 năm trước
Hay lắm a ơi. Mong a ra tiếp những bài viết hữu ích. Cảm ơn a
Trả lời
Avatar
Xuân Hoài Tống1 năm trước
Cảm ơn e, nhớ ghé thăm blog thường xuyên nhé :D
Bấm hoặc cuộn mạnh để sang bài mới