০২ মার্চ, ২০২৫·8 মিনিট পড়তে

ডেভ, স্টেজিং, প্রোড-এর জন্য গোপন ও কনফিগারেশন ম্যানেজমেন্ট

Q: Is using a local .env file okay, or is it always risky?

A local `.env` file is fine for personal development if it never enters version control and never gets baked into images or artifacts. Put it in ignore rules, and avoid sharing it through chat, tickets, or zip files. For staging and production, prefer protected environment settings or a secret manager so you don’t rely on files traveling around.

ডেভ, স্টেজিং, ও প্রোড-এ API কী, SMTP ক্রেডেনশিয়াল ও webhook সিক্রেট লিক ছাড়াই কনফিগারেশন ও সিক্রেট ম্যানেজ করুন—সহজ প্যাটার্ন ও চেকলিস্ট সহ।

আমরা কী সমস্যা সমাধান করছি

গোপনমূল্য এবং কনফিগারেশন ম্যানেজমেন্ট নিয়ে কাজটি হল সংবেদনশীল মানগুলো এমন স্থানে রাখা যাতে তা দুর্ঘটনাবশত কপি, কেশ বা শেয়ার না হয়ে যায়।

একটি secret (গোপন) হলো এমন কিছু যা অ্যাক্সেস দেয় বা পরিচয় প্রমাণ করে — যেমন API কী, ডাটাবেস পাসওয়ার্ড, SMTP লগইন, বা webhook signing secret। সাধারণ config হলো এমন মান যা প্রকাশ করা গেলেও ক্ষতি হয় না, যেমন একটি ফিচার ফ্ল্যাগের নাম, টাইমআউট, বা পাবলিক সাইটের বেস URL।

Dev, staging, এবং prod-এ আলাদা মান থাকা উচিত কারণ তাদের উদ্দেশ্য আলাদা। Dev দ্রুত পরীক্ষা-পরিক্ষার জন্য, staging প্রোডাকশনের অনুরূপ দেখতে কিন্তু বিচ্ছিন্ন থাকার জন্য, এবং prod-কে লকডাউন, অডিটযোগ্য ও স্থিতিশীল রাখতে হয়। একই গোপন সব জায়গায় reuse করলে dev-এ কোনো লিক থাকলেই তা প্রোডাকশনে breach-এ পরিণত হতে পারে।

“Leaking into builds” বলতে বোঝায় কোনো গোপন এমন কিছুতে ঢুকে যাওয়া যা প্যাকেজ হয়ে শেয়ার হয়, যেমন কম্পাইল করা ব্যাকএন্ড বাইনারি, মোবাইল অ্যাপ বান্ডেল, বা ফ্রন্ট-এন্ড বান্ডল। একবার গোপন কোনো বিল্ড আর্টিফ্যাক্টে গেলে তা এমন জায়গায় পৌঁছে যাবে যা আপনি নিয়ন্ত্রণ করেন না।

অ্যাক্সিডেন্টাল লিক সাধারণত কয়েকটি প্রত্যাশিত পথ দিয়ে ঘটে:

সোর্স কোড, স্যাম্পল বা কমেন্টে গোপন হার্ডকোড করা
লোকাল .env ফাইল বা কনফিগ এক্সপোর্ট রেপোতে কমিট করা
ফ্রন্ট-এন্ড বা মোবাইল বিল্ডে গোপন বেক করা যা ব্যবহারকারীর ডিভাইসে চলে
লগ, ক্র্যাশ রিপোর্ট বা বিল্ড আউটপুটে গোপন প্রিন্ট করা
"একটু পরীক্ষা করে দেখার জন্য" প্রোডাকশনের মানগুলো স্টেজিং-এ কপি করা

একটি সহজ উদাহরণ: একজন ডেভ SMTP পাসওয়ার্ড কনফিগ ফাইলে যোগ করে যাতে “ইমেইল কাজ করে,” তারপর ফাইলটি কমিট বা রিলিজ বিল্ডে প্যাকেজ হয়ে যায়। পাসওয়ার্ড পরে রোটেট করলেও পুরানো বিল্ড CI কেশে, অ্যাপ স্টোর আপলোডে, বা কারো ডাউনলোড ফোল্ডারে থাকতে পারে।

লক্ষ্য সহজ: গোপনগুলো কোড ও বিল্ডের বাইরে রাখুন, এবং প্রতিটি এনভায়রনমেন্টে সঠিক মান রানটাইমে বা একটি সিকিউর ডিপ্লয়মেন্ট স্টেপে ইনজেক্ট করুন।

এমন মৌলিক নীতিমালা যা বেশিরভাগ লিক রোধ করে

অধিকাংশ সেফটি আসে কয়েকটি অভ্যাস থেকে যা আপনি প্রতিবার অনুসরণ করবেন।

গোপনগুলো কোড ও বিল্ড আউটপুট থেকে দূরে রাখুন। কোড ছড়ায়—কপি হয়, রিভিউ হয়, লগ হয়, কেশ হয়, আপলোড হয়। বিল্ডও ছড়ায়: আর্টিফ্যাক্ট CI লগ, অ্যাপ বান্ডল, কনটেইনার রেজিস্ট্রি বা শেয়ার্ড ফোল্ডারে পৌঁছে যেতে পারে। যেটা কমিট বা কম্পাইল হয়, সেটাকে পাবলিক ভাবুন।

প্রতিটি এনভায়রনমেন্টের জন্য আলাদা ক্রেডেনশিয়াল ব্যবহার করুন (least privilege)। আপনার dev কী শুধুমাত্র dev-এ কাজ করা উচিত এবং সেটা কি কি করতে পারে তা সীমিত রাখা উচিত। ল্যাপটপ বা টেস্ট সার্ভার থেকে কী লিক হলে ক্ষতি সীমিত থাকে। একই ধারণা SMTP ইউজার, ডাটাবেস পাসওয়ার্ড, ও webhook সিক্রেটে প্রযোজ্য।

রোটেশনকে সাধারণ করুন। ধরে নিন আপনি গোপন রোটেট করবেন; তাই ডিজাইন এমন করুন যাতে মান বদলাতে কোড এডিট বা সব অ্যাপ পুনরায় বিল্ড করার দরকার না পড়ে। অনেক সিস্টেমে এর মানে হলো রুটটাইমে সিক্রেট পড়া (এনভায়রনমেন্ট ভ্যারিয়েবল বা সিক্রেট স্টোর থেকে) এবং ট্রানজিশনের সময় একাধিক সিক্রেট সমর্থন করা।

অ্যাকসেস সীমাবদ্ধ ও লগ করুন। গোপন কেবল সেই সার্ভিসই পড়তে পারবে যেটা দরকার, এবং শুধু সেই এনভায়রনমেন্টে যেখানে চলে। মানুষদের অ্যাকসেস কম, সময়সীমাবদ্ধ এবং অডিটেবল রাখুন।

একটি ছোট রুলসেট যা বেশিরভাগ কেস কভার করবে:

গোপন কমিট করবেন না বা টিকিটে, চ্যাটে, স্ক্রিনশটে পেস্ট করবেন না।
dev, staging, এবং prod-এর জন্য আলাদা ক্রেডেনশিয়াল ব্যবহার করুন।
বিল্ডে মান বেক করার চেয়ে রানটাইম কনফিগ প্রেফার করুন।
সাস্পিশাস এক্সপোজারের পরে বা সময়মত রোটেট করুন।
কে এবং কী পড়তে পারে সেটা সীমাবদ্ধ করুন এবং অ্যাক্সেস লগ রাখুন।

এই নীতিগুলো সাধারণ কোড স্ট্যাক বা AppMaster-এর মতো no-code প্ল্যাটফর্ম দুটোতেই প্রযোজ্য। নিরাপদ পথ একই: গোপনগুলো বিল্ডের বাইরে রাখুন এবং যেখানে ব্যবহার হবে সেখানে কড়া সীমাবদ্ধ করুন।

গোপন কোথা থেকে সবচেয়ে বেশি লিক হয়

বেশিরভাগ লিক “হ্যাক” নয়—সেগুলো সাধারণ কাজের সময় ঘটে: দ্রুত একটি টেস্ট, একটি সহায়ক স্ক্রিনশট, এমন একটি বিল্ড যা বেশি প্রিন্ট করে। শুরু করার ভালো জায়গা হচ্ছে জানা যে ছোট ত্রুটিগুলো সাধারণত কোথায় ঘটে।

Source control হলো ক্লাসিকল। কেউ একটি API কী কনফিগ ফাইলে পেস্ট করে “ইতিমধ্যে” বলে কমিট করে, এবং সেটা ব্রাঞ্চ, পুল রিকোয়েস্ট, ও কোড রিভিউয়ের মধ্যে ছড়িয়ে পড়ে। পরে সেটি সরানো হলেও, গোপন ইতিহাসে বা কপি করা প্যাচে চিরকাল থাকতে পারে।

যা কিছু ইউজারকে শিপ করেন সেটাও বড় লিক সোর্স। ফ্রন্ট-এন্ড বান্ডল এবং মোবাইল বাইনারি পরীক্ষা করে দেখা সহজ। যদি গোপন JavaScript-এ থাকে, iOS/Android অ্যাপ বা ‘বেক করা’ কনফিগে থাকে, ধরে নিন সেটা পাবলিক। ক্লায়েন্ট অ্যাপগুলো পাবলিক আইডেন্টিফায়ার রাখতে পারে, তবে প্রাইভেট কি রাখবে না।

গোপনগুলো "সহায়ক শব্দশৃঙ্খল" হিসেবে অটোমেশন ও সাপোর্টেও লিক হয়। সাধারণ উদাহরণ: CI লগে এনভায়রনমেন্ট ভ্যারিয়েবল ইকো করা, ডিবাগ প্রিন্টে SMTP ক্রেডেনশিয়াল থাকা, ক্র্যাশ রিপোর্টে কনফিগ এবং আউটবাউন্ড রিকোয়েস্টর ক্যাপচার করা, কনটেইনার ইমেজ ও বিল্ড কেশে .env ফাইল ফেলে রাখা, এবং সাপোর্ট টিকেটে কপি করা লগ বা স্ক্রিনশট।

একটি সাধারণ প্যাটার্ন হলো একবার গোপন বিল্ড পাইপলাইনে ঢুকলে সেটা পরে কপি হয়ে যায়: কনটেইনার লেয়ারে, কেশড আর্টিফ্যাক্টে, লগে, আর টিকেটে। সমাধান সাধারণত এক টুল নয়—এটি অভ্যাস: গোপনগুলো কোড, বিল্ড এবং মানুষের পেস্ট করা কিছুর বাইরে রাখুন।

সাধারণ গোপন ধরনের ঝুঁকি

কোন ধরনের গোপন তা জানা সাহায্য করে—লিক হলে কী করতে পারে এবং কোথায় কখনোও উপস্থিত হওয়া উচিত না।

API keys (Stripe, maps, analytics, ইত্যাদি) প্রায়ই “প্রজেক্ট লেভেল” ক্রেডেনশিয়াল। এগুলো আপনার অ্যাপকে শনাক্ত করে এবং নির্দিষ্ট অ্যাকশন করতে দেয়, যেমন কার্ড চার্জ করা বা ইউজেজ স্ট্যাট পড়া। এগুলো ব্যবহারকারী টোকেন নয়—টোকেন সাধারণত সেশন প্রতিনিধিত্ব করে এবং শেষ হয়। অনেক API কী নিজে থেকে এক্সপায়ার করে না, তাই লিক হলে ক্ষতি বড় হতে পারে।

SMTP ক্রেডেনশিয়াল সাধারণত ইউজারনেম এবং পাসওয়ার্ড। এগুলো লিক হলে আক্রমণকারী আপনার ডোমেইন থেকে স্প্যাম পাঠাতে পারবে এবং ডেলিভারিবিলিটি নষ্ট হয়ে যাবে। API-ভিত্তিক ইমেইল প্রদানকারীরা কাঁচা SMTP পাসওয়ার্ডের বদলে API কী ও স্কোপড পারমিশন দেয়, যা নিরাপদ হতে পারে, তবে যদি কী দিয়ে আপনার একাউন্ট থেকে মেইল পাঠানো যায় তবে ঝুঁকি থাকে।

Webhook secrets (signing secrets বা verification keys) ইনবাউন্ড রিকোয়েস্টগুলোকে নিরাপদ রাখে। যদি signing secret লিক হয়, কেউ "payment succeeded" বা "subscription canceled" ইভেন্ট নকল করে আপনার সিস্টেমকে ঠকাতে পারে। ঝুঁকি কেবল ডেটা উন্মোচন নয়—ব্যবসায়িক লজিক নকল ইভেন্টে চালানো।

অন্যান্য উচ্চ-ইমপ্যাক্ট সিক্রেটগুলোর মধ্যে আছে ডাটাবেস URL (অধিকাংশ সময় এমবেড করা পাসওয়ার্ড সহ), সার্ভিস অ্যাকাউন্ট ক্রেডেনশিয়াল, এবং এনক্রিপশন কী। একটি লিক হওয়া ডাটাবেস URL মানে পূর্ণ ডেটা চুরি হতে পারে। একটি লিক হওয়া এনক্রিপশন কী অতীত ও ভবিষ্যতের ডেটাকে পড়ার যোগ্য করে তুলতে পারে, এবং রোটেশন কষ্টসাধ্য হতে পারে।

ইমপ্যাক্ট বোঝার দ্রুত উপায়:

টাকা খরচ করতে বা অ্যাকশন ট্রিগার করতে পারে: payment keys, admin API keys, webhook signing secrets
আপনি হিসেবে ছদ্মবেশ ধারণ করতে পারে: SMTP পাসওয়ার্ড, ইমেইল সেন্ডিং কী, মেসেজিং বট টোকেন
সব ডেটা উন্মোচন করতে পারে: ডাটাবেস ক্রেডেনশিয়াল, ক্লাউড সার্ভিস একাউন্ট
গোপনীয়তা স্থায়ীভাবে ভেঙে দিতে পারে: এনক্রিপশন কী, সাইনিং কী
প্রায়ই শিপ করা নিরাপদ: ব্রাউজারের জন্য পাবলিশেবল কী (এখনও ডোমেইন/অ্যাপ দ্বারা সীমাবদ্ধ করুন)

কখনই ক্লায়েন্ট অ্যাপে পাঠাবেন না: secret API keys, SMTP ক্রেডেনশিয়াল, ডাটাবেস পাসওয়ার্ড, সার্ভিস অ্যাকাউন্ট, প্রাইভেট এনক্রিপশন কী, এবং webhook signing secrets। যদি ক্লায়েন্টকে থার্ড-পার্টি API কল করতে হয়, ব্যাকএন্ডের মধ্য দিয়ে রাউট করুন যাতে সিক্রেট সার্ভার-সাইডেই থাকে।

বিল্ডে গোপন না ঢুকিয়ে রাখার প্যাটার্ন

Create a safer admin workflow

Create an authenticated admin panel to manage integrations without exposing sensitive values.

Build Panel

একটি নিরাপদ ডিফল্ট সহজ: কোন কিছু কম্পাইল, এক্সপোর্ট বা শেয়ার করা হলে তাতে গোপন বেক করবেন না। বিল্ডকে পাবলিক আর্টিফ্যাক্ট ভাবুন, এমনকি আপনি মনে করেন সেগুলো প্রাইভেট।

প্রতিটি এনভায়রনমেন্টের জন্য সঠিক কনটেইনার চয়ন করুন

লোকাল ডেভেলপমেন্টের জন্য, একটি কনফিগ ফাইল ঠিক আছে যদি এটি ভার্সন কন্ট্রোলে না যায় এবং সহজে প্রতিস্থাপনযোগ্য হয় (উদাহরণ: লোকাল-অনলি .env স্টাইল ফাইল)। Staging এবং production-এর জন্য, একটি রিয়েল সিক্রেট স্টোর পেফার করুন: ক্লাউড প্রোভাইডারের সিক্রেট ম্যানেজার, একটি ডেডিকেটেড ভল্ট, বা আপনার প্ল্যাটফর্মের প্রটেক্টেড এনভায়রনমেন্ট সেটিংস।

Environment variables ভাল ডিফল্ট কারণ সেগুলো রানটাইমে ইনজেক্ট করা সহজ এবং কোডবেস থেকে আলাদা রাখা যায়। মূল বিষয় হলো টাইমিং: বিল্ড-টাইম ইনজেকশন না করে রানটাইম ইনজেকশন করা নিরাপদ কারণ সিক্রেট আর বিল্ড আউটপুটের অংশ হয় না।

একটি ব্যবহারিক বিভাজন যা অনেক টিমের জন্য কাজ করে:

Local dev: লোকাল env vars বা লোকাল সিক্রেট ফাইল, প্রতিটি ডেভের মেশিন আলাদা
Staging: সিক্রেট ম্যানেজার বা প্রটেক্টেড এনভায়রনমেন্ট সেটিংস, শুধুই স্টেজিংের জন্য স্কোপড
Production: আরও কড়া অ্যাক্সেস কনট্রোল, অডিট লগ, এবং রোটেশনসহ সিক্রেট ম্যানেজার

নামকরণ ও বাউন্ডারি একরকম রাখুন

প্রতিটি এনভায়রনমেন্টে একই কী নাম ব্যবহার করুন যাতে অ্যাপ আচরণ একই থাকে: SMTP_HOST, SMTP_USER, SMTP_PASS, STRIPE_SECRET_KEY, WEBHOOK_SIGNING_SECRET। শুধু ভ্যালু বদলান।

যখন এনভায়রনমেন্ট গুরুত্ব পায় (পেমেন্ট, ইমেইল, ওয়েবহুক), সম্ভব হলে আলাদা প্রজেক্ট বা ক্লাউড একাউন্ট ব্যবহার করুন। উদাহরণস্বরূপ, স্টেজিং Stripe কী ও webhook secret স্টেজিং-ওনলি স্টোরে রাখুন যাতে স্টেজিং মিসকনফিগারেশন প্রোডাকশনকে স্পর্শ না করে।

যদি আপনি AppMaster ব্যবহার করে ডিপ্লয় করেন, ব্যাকএন্ড সার্ভিসের জন্য রানটাইম এনভায়রনমেন্ট সেটিংস পছন্দ করুন যাতে সিক্রেট সার্ভার-সাইডেই থাকে এবং এক্সপোর্টেড কোড বা ক্লায়েন্ট অ্যাপে এমবেড না হয়।

ডেভ, স্টেজিং, প্রোড-এ ধাপে ধাপে সেটআপ

Handle email the server way

Send emails from backend endpoints so SMTP credentials never reach browsers or devices.

Create Backend

অপব্যবহার কঠিন করে দিন।

আপনার কী আছে এবং কোথায় ব্যবহার হচ্ছে তা ইনভেন্টরি করুন। API কী, SMTP ইউজারনেম ও পাসওয়ার্ড, webhook signing secret, ডাটাবেস পাসওয়ার্ড, JWT সাইনিং কী, এবং থার্ড-পার্টি টোকেন অন্তর্ভুক্ত করুন। প্রতিটির জন্য মালিক (টিম বা ভেন্ডর), যে কম্পোনেন্ট পড়ে (ব্যাকএন্ড, ওয়ার্কার, মোবাইল, ওয়েব), এবং রোটেশন কত ঘনই হতে পারে তা নোট করুন।
Dev, staging, এবং prod-এর জন্য আলাদা ভ্যালু এবং আলাদা পারমিশন তৈরি করুন। Dev সিক্রেটগুলো ল্যাপটপ এবং লোকাল কন্টেইনার থেকে নিরাপদে ব্যবহারযোগ্য হওয়া উচিত। Staging প্রোডের মতো দেখতে হবে, কিন্তু কখনো প্রোড ক্রেডেনশিয়াল শেয়ার করা যাবে না। Prod কেবল প্রোডাকশন রানটাইম আইডেন্টিটি পড়তে পারবে, মানুষ ডিফল্টভাবে নয়।
সিক্রেটগুলো বিল্ড টাইম নয়, রানটাইম কনফিগে সরান। যদি কোনো সিক্রেট বিল্ডের সময় উপস্থিত থাকে, তা বিল্ড লগ, Docker লেয়ার, ক্লায়েন্ট বান্ডল, বা ক্র্যাশ রিপোর্টে পড়ে যেতে পারে। সহজ নিয়ম: বিল্ড এমন আর্টিফ্যাক্ট তৈরি করে যা কপি করা নিরাপদ; সিক্রেট কেবল অ্যাপ আরম্ভের সময় ইনজেক্ট করা হয়।
একটি ধারাবাহিক ডিপ্লয়মেন্ট ফ্লো ব্যবহার করুন। একটি পদ্ধতি যা টিমকে সমস্যায় ফেলার সম্ভাবনা কম রাখে:

প্রতিটি এনভায়রনমেন্টের জন্য একটি সিক্রেট স্টোর তৈরি করুন (বা কড়া namespace)।
অ্যাপের runtime identity-কে কেবল নিজ পরিবেশের সিক্রেট পড়ার অনুমতি দিন।
স্টার্টআপে এনভায়রনমেন্ট ভ্যারিয়েবল বা মাউন্ট করা ফাইলের মাধ্যমে সিক্রেট ইনজেক্ট করুন, এবং সেগুলো ইমেজ বা ফ্রন্ট-এন্ড বান্ডলে রাখবেন না।
প্রতিটি সিক্রেটের জন্য রোটেশন নিয়ম (মেয়াদ, মালিক, এবং রিমাইন্ডার ক্যাডেন্স) যোগ করুন।
একটি শক্ত টেস্ট যোগ করুন: যদি স্টেজিং কখনও প্রোড সিক্রেট পড়ার চেষ্টা করে, ডিপ্লয় ব্যর্থ হবে।

লকডাউন মানে প্রধানত কে এবং কী পড়তে পারে তা কমানো। শেয়ার্ড একাউন্ট এড়ান, দীর্ঘজীবী টোকেন যতটা সম্ভব পরিহার করুন, এবং রিড পারমিশন লেখার তুলনায় সঙ্কুচিত রাখুন।

AppMaster-এর মতো no-code প্ল্যাটফর্ম ব্যবহার করলে একই পদ্ধতি কাজ করে: থার্ড-পার্টি ক্রেডেনশিয়াল এনভায়রনমেন্ট-স্পেসিফিক রানটাইম সেটিংসে রাখুন, এবং জেনারেট করা বিল্ড আর্টিফ্যাক্টগুলোকে টিমের ভিতরেই পাবলিক হিসেবে বিবেচনা করুন। এই এক সিদ্ধান্ত অনেক দুর্ঘটনাজনিত লিক প্রতিরোধ করে।

API কী ও SMTP ক্রেডেনশিয়ালের ব্যবহারিক প্যাটার্ন

অনেক লিক ঘটে যখন অ্যাপকে “কিছু পাঠাতে” হয় এবং দ্রুত সমাধান হিসেবে ক্রেডেনশিয়ালকে ক্লায়েন্টে পেস্ট করা বা কনফিগ ফাইলে রেখে দেওয়া হয় যা বান্ডলে পড়ে যায়। একটি ভাল ডিফল্ট রুল: ওয়েব ও মোবাইল ক্লায়েন্ট কখনো SMTP ইউজারনেম, SMTP পাসওয়ার্ড বা এমন কোনো প্রোভাইডার কী রাখবে না যা মেসেজ পাঠাতে পারে।

ইমেইলের জন্য, সম্ভব হলে কাঁচা SMTP-এর বদলে ইমেইল প্রোভাইডারের API কী ব্যবহার করুন। API-ভিত্তিক সেন্ডিং স্কোপড করা সহজ (শুধু মেইল পাঠাতে পারে), রোটেট ও মনিটর করা সহজ। যদি SMTP ব্যবহারই করতে হয়, সার্ভার-সাইডেই রাখুন এবং ব্যাকএন্ডকে একক ইন্টারফেস বানান যেটাই মেল সার্ভারের সাথে কথা বলে।

সুরক্ষিত সেটআপ উদাহরণ:

ইমেইল সেন্ডিংকে ব্যাকএন্ড এন্ডপয়েন্টের পিছনে রাখুন (উদাহরণ: “send password reset” বা “send invoice”)।
API কী বা SMTP পাসওয়ার্ড ব্যাকএন্ডের এনভায়রনমেন্ট সিক্রেটে স্টোর করুন, সোর্স কোড বা UI সেটিংসে নয়।
Dev, staging, এবং prod-এর জন্য আলাদা ক্রেডেনশিয়াল ব্যবহার করুন (আইডিয়ালি আলাদা অ্যাকাউন্ট ও সেন্ডার ডোমেইন)।
স্টেজিং রিসিপিয়েন্ট allowlist রাখুন যাতে কেবল অনুমোদিত ঠিকানাগুলিতেই মেইল যাবে।
ডেলিভারি ফলাফল লগ করুন (message ID, provider response, recipient domain) কিন্তু ক্রেডেনশিয়াল বা সম্পূর্ণ মেসেজ বডি কখনো লগ করবেন না।

স্টেজিং ও প্রোড আলাদা না রাখাটা বেশি ঝুঁকিপূর্ণ—স্টেজিং সার্ভার ভুল করলেই বাস্তব গ্রাহকদের কাছে স্প্যাম পৌঁছাতে পারে যদি একই সেন্ডার ও রুল শেয়ার করা হয়। একটি সহজ গার্ড: স্টেজিং-এ আউটবাউন্ড ইমেইল ব্লক করুন যদি রিসিপিয়েন্ট allowlist-এ না থাকে (যেমন আপনার টিমের ঠিকানাগুলো)।

উদাহরণ: আপনি AppMaster-এ একটি কাস্টমার পোর্টাল বানাচ্ছেন। মোবাইল অ্যাপ "login code পাঠাও" ট্রিগার করে। অ্যাপ ব্যাকএন্ড কল করে, ব্যাকএন্ড প্রোড বা স্টেজিং মেইল সিক্রেট পড়ে এবং মেইল পাঠায়। টেস্টার স্টেজিং ব্যবহার করলে allowlist বাস্তব গ্রাহকদের কাছে মেসেজ থামায়, এবং লগগুলো দেখায় যে পাঠ সফল হয়েছে কিনা কিন্তু কী এক্সপোজ করছে না।

Webhook সিক্রেট: সাইনিং, ভেরিফিকেশন, ও রোটেশন

Keep secrets out of builds

Build your backend in AppMaster and inject secrets at runtime per environment.

Try AppMaster

Webhook সিকিউরিটি একটি নিয়মে যাচ্ছে: প্রতিটি রিকোয়েস্ট সার্ভার-সাইডে ভেরিফাই করুন এমন একটি সিক্রেট দিয়ে যা বাইরে যায় না। যদি সিক্রেট ওয়েব বা মোবাইল অ্যাপে চলে যায়, তা আর সিক্রেট থাকে না।

সাইনিং ও ভেরিফিকেশন

একটা webhookকে ইনকামিং কার্ড পেমেন্টের মতো চিন্তা করুন: ভেরিফাই না হওয়া পর্যন্ত কিছু গ্রহণ করবেন না। প্রোভাইডার একটি সিগনেচার হেডার পাঠায় যা পেলোড ও আপনার শেয়ার্ড সিক্রেট ব্যবহার করে হিসাব করা। আপনার সার্ভার প্রত্যাশিত সিগনেচার পুনরায় হিসাব করে এবং তুলনা করে।

সহজ ভেরিফিকেশন ফ্লো:

রিকোয়েস্ট বডি অনুলিপি নেবেন না—কাঁচা বডি ঠিক যেভাবে এসেছে তেমন পড়ুন।
আপনার webhook সিক্রেট ব্যবহার করে প্রত্যাশিত সিগনেচার গণনা করুন।
কনস্ট্যান্ট-টাইম তুলনা ব্যবহার করুন।
অনুপস্থিত বা অবৈধ সিগনেচারকে স্পষ্ট 401 বা 403 দিয়ে প্রত্যাখ্যান করুন।
তারপরই JSON পার্স করে ইভেন্ট প্রসেস করুন।

Dev, staging, এবং prod-এ আলাদা webhook এন্ডপয়েন্ট এবং আলাদা সিক্রেট ব্যবহার করুন। এতে একটি dev টুল বা টেস্ট সিস্টেম প্রোড অ্যাকশন ট্রিগার করতে পারবে না, এবং ইনসিডেন্ট কনটেইন করা সহজ হয়। AppMaster-এ সাধারণত প্রতিটি ডিপ্লয়মেন্টের জন্য আলাদা এনভায়রনমেন্ট কনফিগ থাকে, এবং webhook secret সার্ভার-সাইড ভ্যারিয়েবল হিসেবে রাখা হয়, UI বা মোবাইল/ওয়েব ক্লায়েন্টে নয়।

রেপ্লে প্রোটেকশন ও রোটেশন

সিগনেচার টেম্পারিং থামায়, কিন্তু স্বয়ংক্রিয়ভাবে রেপ্লে থামায় না। প্রতিটি রিকোয়েস্টকে একবারই বৈধ করে তুলুন, বা শুধুমাত্র একটি সংক্ষিপ্ত সময় উইন্ডোতে গ্রহণ করুন। সাধারণ অপশনগুলো হলো টাইমস্ট্যাম্প হেডার সহ কড়া সময়সীমা, ননস, বা একটি idempotency কী যা আপনি স্টোর করে পুনরায় প্রক্রিয়া করতে অস্বীকার করেন।

রোটেশন পরিকল্পনা আগে থেকে রাখুন। একটি নিরাপদ প্যাটার্ন হলো সংক্ষিপ্ত overlap-এ দুইটি সক্রিয় সিক্রেট সমর্থন করা: আপনি provider-কে আপডেট করার সময় উভয় সিক্রেট গ্রহণ করুন, তারপর পুরাতনটি রিটায়ার করুন। একটি পরিষ্কার কাটঅফ সময় রাখুন এবং পুরনো সিগনেচারের ট্রাফিক মনিটর করুন।

লগ নিয়ে সাবধান থাকুন। Webhook পেলোডে প্রায়ই ইমেইল, ঠিকানা বা পেমেন্ট মেটাডেটা থাকে। ইভেন্ট ID, টাইপ এবং ভেরিফিকেশন ফলাফল লগ করুন, কিন্তু পুরো পেলোড বা হেডার প্রিন্ট করা থেকে বিরত থাকুন।

সাধারণ ভুল এবং ট্য্র্যাপ

অধিকাংশ লিক সহজ অভ্যাস থেকে আসে যা ডেভেলপমেন্টে সুবিধাজনক লাগে, তারপর স্টেজিং ও প্রোডাকশনে কপি হয়ে যায়।

লোকাল .env ফাইলকে চিরকাল নিরাপদ স্থানে মনে করা একটি সাধারণ ত্রুটি। আপনার ল্যাপটপে এটা ঠিক আছে, কিন্তু একটি মুহূর্তে তা রেপোতে, শেয়ার্ড জিপে বা ডকার ইমেজে কপি হলে সেটা বিপজ্জনক। যদি আপনি .env ব্যবহার করেন, নিশ্চিত করুন এটি ভার্সন কন্ট্রোলে ignore করা আছে এবং বাস্তবে ডিপ্লয়মেন্টে এনভায়রনমেন্ট সেটিংস ব্যবহার করা হচ্ছে।

একই ক্রেডেনশিয়াল সব জায়গায় ব্যবহার করা আরেকটি সাধারণ সমস্যা। একক API কী dev, staging, এবং prod-এ reuse করলে dev-এ কোনো ভুল প্রোড ইনসিডেন্টে পরিণত হতে পারে। আলাদা কী রোটেট, রিভোক এবং অডিট করা সহজ করে।

ওয়েব ফ্রন্টএন্ড ও মোবাইল অ্যাপে বিল্ড টাইমে সিক্রেট ইনজেকশন করা বিশেষভাবে ঝুঁকিপূর্ণ। যদি কোনো গোপন কম্পাইল্ড বান্ডলে বা অ্যাপ প্যাকেজে পড়ে যায়, ধরে নিন তা এক্সট্রাক্ট করা যাবে। ফ্রন্টেন্ডগুলো কেবল পাবলিক কনফিগ রাখতে পারে (যেমন বেস API URL)। সংবেদনশীল কিছু সার্ভারের মাধ্যমে রুট করা উচিত।

লগ একটি চুপচাপ লিক সোর্স। "অস্থায়ী" ডিবাগ প্রিন্ট মাসগুলোর জন্য থাকতে পারে এবং শিপ হয়ে যেতে পারে। যদি মান নিশ্চিত করতে লগ করতে হয়, কেবল মাস্ক করা সংস্করণ লগ করুন (উদাহরণ: শেষ 4 অক্ষর) এবং সটেই স্টেটমেন্টটি সরিয়ে দিন।

রেড ফ্ল্যাগ যা সাধারণত সমস্যা বোঝায়

গোপন Git ইতিহাসে দেখা যায়, এমনকি পরে সরানো হয়েছে বলেও।
একটি কী সব এনভায়রনমেন্টে কাজ করে।
একটি মোবাইল অ্যাপে ভেন্ডর কী বা SMTP পাসওয়ার্ড আছে।
সাপোর্ট টিকেটে পূর্ণ রিকোয়েস্ট ডাম্প আছে হেডারসহ।
মানগুলো Base64-এ রাখা বা ফর্ম ফিল্ডে "লুকানো" আছে।

এনকোডিং সুরক্ষা নয়, এবং লুকানো ফিল্ড ব্যবহারকারীর জন্য এখনও দৃশ্যমান।

AppMaster-এ কাজ করলে, প্রতিটি ডিপ্লয়মেন্ট টার্গেটের জন্য এনভায়রনমেন্ট-লেভেল কনফিগে সংবেদনশীল মান রাখুন এবং ক্লায়েন্ট অ্যাপে শুধুমাত্র অ-সংবেদনশীল সেটিং পাস করুন। একটি বাস্তবতাচেক: ব্রাউজার যদি দেখতে পারে, সেটা পাবলিক ভাবুন।

শিপ করার আগে দ্রুত চেকলিস্ট

Ship web and mobile securely

Generate web and native mobile apps without embedding private keys in client bundles.

Build App

"কী লিক হতে পারে" এই মনোভাব নিয়ে একটি ফাইনাল পাস করুন। বেশিরভাগ ইনসিডেন্ট অপ্রীতিকর এবং সাধারণ: একটি কী টিকটে পেস্ট করা, কনফিগ প্যানেলের স্ক্রিনশট, বা বিল্ড আর্টিফ্যাক্ট যা চুপচাপ গোপন অন্তর্ভুক্ত করে।

শিপ করার আগে এই ভিত্তিগুলো যাচাই করুন:

গোপনগুলো রেপো ইতিহাসে, ইস্যু, ডকস, স্ক্রিনশট বা চ্যাট লগে নেই। যদি কখনো পেস্ট করা হয়ে থাকে, ধরে নিন তা সম্মুখভাগে প্রকাশিত হয়েছে এবং রোটেট করুন।
আপনার ওয়েব ও মোবাইল বিল্ডে কেবল পাবলিক সেটিংস আছে (যেমন API বেস URL বা ফিচার ফ্ল্যাগ)। প্রাইভেট কীগুলি, SMTP পাসওয়ার্ড, এবং webhook signing secrets সার্ভার-সাইডে বা এনভায়রনমেন্ট-স্পেসিফিক সিক্রেট স্টোরে থাকা উচিত।
স্টেজিং প্রোডাকশন থেকে বিচ্ছিন্ন। স্টেজিংয়ের আলাদা API কী, আলাদা SMTP একাউন্ট, এবং আলাদা webhook secret থাকা উচিত। স্টেজিং কখনো প্রোড ডাটাবেস বা প্রোড সিক্রেট ম্যানেজার পড়ার ক্ষমতা থাকা উচিত নয়।
CI লগ, মনিটরিং, এবং এরর রিপোর্টিং সংবেদনশীল মান প্রিন্ট করে না। বিল্ড আউটপুট, ক্র্যাশ রিপোর্ট এবং ডিবাগ লগ চেক করুন। টোকেন মাস্ক করুন এবং Authorization মতো হেডারগুলো রেড্যাক্ট করুন।
আপনি দ্রুত কোড পরিবর্তন ছাড়া রোটেট ও রিভোক করতে পারেন। নিশ্চিত করুন সিক্রেট ডিপ্লয় টাইমে ইনজেক্ট করা হয় (এনভায়রনমেন্ট ভ্যারিয়েবল বা সিক্রেট ম্যানেজার), তাই কী পরিবর্তন একটি কনফিগ আপডেটে হয়ে যায়, জরুরি পুনর্বিল্ড নয়।

AppMaster ব্যবহার করলে, প্রতিটি এনভায়রনমেন্টের জন্য সিক্রেটগুলোকে ডিপ্লয়মেন্ট-টাইম কনফিগ মনে করুন, UI স্ক্রিন বা এক্সপোর্টেড বিল্ডে নয়। একটি দরকারী শেষ চেক হলো কম্পাইলড আর্টিফ্যাক্ট ও লগে সাধারণ প্যাটার্নগুলোর জন্য সার্চ করা, যেমন sk_live, Bearer , বা SMTP হোস্টনেম।

প্রতিটি ইন্টিগ্রেশনের জন্য “কিল সুইচ” লিখে রাখুন: কী কোথায় ডিজেবল করবেন, এবং কে তা পাঁচ মিনিটের মধ্যে করতে পারে।

উদাহরণ দৃশ্য: পেমেন্ট, ইমেইল, এবং ওয়েবহুক

Turn incident steps into automation

Use the Business Process Editor to automate key revokes and rotations after exposure.

Automate Now

একটি তিন-জনের টিম একটি কাস্টমার পোর্টাল (ওয়েব), একটি মোবাইল অ্যাপ, এবং ছোট ব্যাকগ্রাউন্ড জব চালায় যা রসিদ পাঠায় ও ডেটা সিঙ্ক করে। তাদের তিনটি এনভায়রনমেন্ট আছে: লোকাল dev, QA-এর জন্য staging, এবং বাস্তব ব্যবহারকারীর জন্য prod। তারা চায় এমন একটি সিক্রেট ও কনফিগ সেটআপ যা দৈনন্দিন কাজকে ধীর করে দেবে না।

Dev-এ তারা কেবল স্যান্ডবক্স পেমেন্ট কী ও টেস্ট SMTP একাউন্ট ব্যবহার করে। প্রতিটি ডেভ তার লোকাল এনভায়রনমেন্ট ভ্যারিয়েবলে সিক্রেট রাখে (বা একটি লোকাল আনট্র্যাকড ফাইল যা env ভ্যারিয়েবলে লোড হয়), যাতে কিছুই রেপোতে না যায়। ওয়েব অ্যাপ, মোবাইল অ্যাপ, ও ব্যাকগ্রাউন্ড জব একই ভ্যারিয়েবল নাম পড়ে — যেমন PAYMENTS_KEY, SMTP_USER, এবং WEBHOOK_SECRET—কিন্তু প্রতিটি এনভায়রনমেন্টে ভ্যালুগুলো আলাদা।

Staging-এ CI বিল্ড ডিপ্লয় করে, এবং প্ল্যাটফর্ম রানটাইমে সিক্রেট ইনজেক্ট করে। Staging নিজের পেমেন্ট একাউন্ট, নিজের SMTP ক্রেডেনশিয়াল এবং নিজের webhook signing secret ব্যবহার করে। QA বাস্তব ফ্লো টেস্ট করতে পারে কিন্তু প্রোড সিস্টেমে আঘাত হবেনা।

Prod-এ একই বিল্ড আর্টিফ্যাক্ট ডিপ্লয় করা হয়, কিন্তু সিক্রেটগুলো একটি ডেডিকেটেড সিক্রেট স্টোর (বা ক্লাউড প্রোভাইডারের সিক্রেট ম্যানেজার) থেকে আসে এবং কেবল রানিং সার্ভিসগুলোই সেগুলো পড়তে পারে। টিম আরও টাইট পারমিশন দেয়: কেবল ব্যাকগ্রাউন্ড জব SMTP ক্রেডেনশিয়াল পড়বে, এবং কেবল webhook হ্যান্ডলার webhook secret পড়বে।

কোনো কী এক্সপোজ হলে (উদাহরণ: একটি স্ক্রিনশট API কী দেখায়), তাদের ফিক্সড প্লেবুক আছে:

এক্সপোজ হওয়া কী অবিলম্বে রিভোক করে এবং সম্পর্কিত সিক্রেট রোটেট করুন।
এক্সপোজারের সময়কালের মধ্যে সন্দেহজনক ব্যবহার লগগুলো খুঁজুন।
নতুন ভ্যালু পেতে সার্ভিসগুলো পুনরায় ডিপ্লয় করুন।
কী ঘটেছে তা ডকুমেন্ট করুন এবং একটি গার্ডরেইল যোগ করুন (যেমন pre-commit স্ক্যান)।

লোকাল কাজ সহজ রাখতে, তারা কখনো প্রোড সিক্রেট শেয়ার করে না। ডেভরা স্যান্ডবক্স অ্যাকাউন্ট ব্যবহার করে, এবং যদি AppMaster-র মতো no-code টুল ব্যবহার করে, তারা dev, staging, এবং prod-এর জন্য আলাদা এনভায়রনমেন্ট ভ্যালু সংরক্ষণ করে যাতে একই অ্যাপ লজিক সব জায়গায় নিরাপদে চলে।

পরবর্তী ধাপ: আপনার ওয়ার্কফ্লোতে এটি পুনরাবৃত্তিমূলক করুন

গোপন নিয়ে কাজটাকে হাইজিনের মতো আচরণ করুন। প্রথমবার এটা জটিল মনে হবে, পরে রুটিন হয়ে যাবে।

শুরু করুন একটি সহজ সিক্রেট ম্যাপ লিখে:

সিক্রেটটি কী (API key, SMTP password, webhook secret)
কোথায় ব্যবহার হয় (সার্ভিস, জব, মোবাইল অ্যাপ, ভেন্ডর ড্যাশবোর্ড)
প্রতিটি এনভায়রনমেন্টে কোথায় স্টোর করা আছে (dev, staging, prod)
কে অ্যাক্সেস করতে পারে (মানুষ, CI/CD, কেবল রানটাইম)
কীভাবে রোটেট করবেন (ধাপ এবং কি মনিটর করবেন)

এরপর, প্রতিটি এনভায়রনমেন্টের জন্য একটি স্টোরেজ প্যাটার্ন বাছুন এবং সেটি মেনে চলুন। সঙ্গতি কেয়ারফুল কৌশলের চেয়ে বেশি কাজে লাগে। উদাহরণ: ডেভরা লোকাল সিক্রেট স্টোর ব্যবহার করে, স্টেজিং ম্যানেজড সিক্রেটস ব্যবহার করে সীমিত অ্যাক্সেসসহ, এবং প্রোডাকশন একই ম্যানেজড সিক্রেটস ব্যবহার করে আরও কড়া অডিট সহ।

রোটেশনের সময়সূচী এবং একটি ছোট ইনসিডেন্ট প্ল্যান যোগ করুন যা মানুষ বাস্তবে ফলো করবে:

উচ্চ-ঝুঁকিপূর্ণ কীগুলো ক্যালেন্ডারে রোটেট করুন (এবং স্টাফ পরিবর্তনের পরে অবিলম্বে)।
লিক ধরে নিন: রিভোক, রিপ্লেস, এবং নিশ্চিত করুন ট্রাফিক পুনরুদ্ধার করে।
কে কখন কী রোটেট করেছে তা লগ করুন।
ব্লাস্ট রেডিয়াস চেক ঠিক করুন (পেমেন্ট, ইমেইল সেন্ডিং, ওয়েবহুক)।

আপনি যদি AppMaster (appmaster.io) দিয়ে বানান, প্রাইভেট কীগুলো সার্ভার-সাইড কনফিগে রাখুন এবং এনভায়রনমেন্ট অনুযায়ী ডিপ্লয় করুন যাতে ওয়েব ও মোবাইল বিল্ডগুলিতে গোপন এমবেড না হয়। তারপর একবার স্টেজিং দিয়ে পুরো প্রক্রিয়া পরীক্ষা করুন: একটি কী রোটেট করুন এন্ড-টু-এন্ড (স্টোর আপডেট, রিডিপ্লয়, ভ্যারিফায়, পুরানো কী রিটায়ার)। একবার প্রমাণিত হলে, পরের সিক্রেটে একই প্রক্রিয়া পুনরাবৃত্তি করুন।

প্রশ্নোত্তর

A secret is any value that proves identity or grants access, like API keys, database passwords, SMTP logins, and webhook signing secrets. Config is a value that can be public without harm, like timeouts, feature flag names, or a public site base URL.

If a value would cause damage when copied from a screenshot or a repo, treat it as a secret.

Use separate secrets to keep the blast radius small. If a dev laptop, test server, or staging app leaks a key, you don’t want that key to also unlock production.

Separate environments also let you use safer permissions in dev and staging, and stricter, auditable access in production.

Assume anything compiled, bundled, exported, or uploaded can be copied and inspected later. Keep secrets out of source code and out of build-time variables, and inject them at runtime through environment variables or a secret manager.

If you can swap a secret without rebuilding the app, you’re usually on the safer path.

A local .env file is fine for personal development if it never enters version control and never gets baked into images or artifacts. Put it in ignore rules, and avoid sharing it through chat, tickets, or zip files.

For staging and production, prefer protected environment settings or a secret manager so you don’t rely on files traveling around.

Don’t put private keys, SMTP passwords, database credentials, or webhook signing secrets in any client app. If the code runs on a user device or in a browser, assume attackers can extract values from it.

Instead, route sensitive actions through your backend so the secret stays server-side and the client only sends a request.

Design rotation to be a configuration change, not a code change. Store secrets outside the codebase, redeploy services to pick up new values, and keep a clear owner and reminder cadence for each key.

When possible, allow a short overlap where both old and new secrets work, then retire the old one after traffic confirms the change.

Verify every webhook request on the server using a secret that never leaves the backend. Compute the expected signature from the raw request body exactly as received and compare it safely before you parse and process the event.

Use different webhook endpoints and secrets per environment so test events can’t trigger production actions.

Avoid printing secrets, full headers, or full payloads into logs, build output, or crash reports. If you need troubleshooting, log metadata like event IDs, status codes, and masked values, not credentials.

Treat any pasted log in a ticket or chat as potentially public and redact before sharing.

Staging should mimic production behavior but remain isolated. Use separate vendor accounts or projects where you can, separate SMTP credentials, separate payment keys, and separate webhook secrets.

Add a guardrail so staging cannot read production secret stores or databases, even if someone misconfigures a deployment.

In AppMaster, keep sensitive values in environment-specific runtime settings for each deployment target, not in UI screens or client-side configuration. That helps ensure generated web and mobile builds carry only public settings, while secrets stay on the server.

A good practice is to keep the same variable names across dev, staging, and prod and only change the values per environment.