Property-Based Testing: AI Code में छुपे Security Bugs पकड़ें

75th test run. एक ऐसा input, जो कोई इंसान शायद कभी सोचकर नहीं लिखता. और फिर भी वही input आपके product के “secure” दिखने वाले code को तोड़ देता है.

यही property-based testing (PBT) का असली फायदा है—ये आपके bias को bypass करता है। खासकर तब, जब आप AI-generated code को production के करीब ला रहे हों। “साइबर सुरक्षा में AI” सीरीज़ के लिए ये कहानी इसलिए जरूरी है क्योंकि 2025 में startup teams पहले से ज़्यादा तेजी से ship कर रही हैं, और security regressions अक्सर वहीं छुपते हैं: edge cases, weird strings, और assumptions के बीच।

यह पोस्ट एक real-world pattern पर आधारित है: एक chat app के localStorage-based API key storage में एक subtle JavaScript security weakness, जो unit tests और code review में आसानी से निकल जाती—लेकिन PBT ने उसे पकड़ लिया। और आपके startup के लिए lessons बहुत practical हैं: requirements से properties निकालना, PBT को CI में fit करना, और prototype pollution जैसी classes of bugs को early stage पर रोकना।

Property-Based Testing startups के लिए इतना काम क्यों करती है?

Answer first: PBT आपको “कुछ examples सही हैं” नहीं, बल्कि “बहुत सारे inputs पर behavior stable है” का evidence देती है—और security failures अक्सर वहीं निकलते हैं जहाँ examples नहीं पहुँचते।

Startup environments में दो चीजें साथ-साथ होती हैं: (1) तेज iteration, (2) partial specs. AI tools code जल्दी बना देते हैं, लेकिन correctness और सुरक्षा के assumptions वही रहते हैं जो humans रखते हैं। PBT का stance अलग है: मैं तुम्हारे assumptions पर भरोसा नहीं करूँगा; मैं inputs generate करके तुम्हें prove करने दूँगा।

Traditional unit tests का problem ये नहीं कि वो useless हैं। problem ये है कि:

• आप वही test करते हैं जो आप imagine कर सकते हैं
• attacker वो input चुनता है जो आप imagine नहीं करते

PBT में आप एक property लिखते हैं—एक ऐसा rule जो हर valid input के लिए सही होना चाहिए—और tool random (और targeted) inputs से उसे तोड़ने की कोशिश करता है। Security के लिए ये mindset बहुत natural है: attacker भी तो यही करता है।

“AI ने लिखा है” = “safe है” वाला myth

AI-generated code अक्सर clean दिखता है, idiomatic भी होता है, और code review में pass भी हो जाता है। लेकिन security bugs style नहीं होते—वो semantics होते हैं। Prototype pollution, path traversal, unicode trickery, serialization quirks… ये सब “clean code” में भी आ सकते हैं।

इसलिए AI in cybersecurity का practical meaning सिर्फ threat detection नहीं है; AI-assisted secure development भी उतना ही जरूरी है।

The case: API key storage में एक round-trip property

Answer first: जब requirement को property में बदला गया—“जो key save की, वही load हो”—तो PBT ने एक ऐसा provider name निकाला जिसने JavaScript object system के prototype behavior को trigger कर दिया।

Scenario simple है: एक chat app, जो अलग-अलग LLM providers के लिए API keys save करती है (जैसे openai, anthropic) और localStorage में store करती है। Requirement के हिसाब से:

• user key save करे
• app उसे local storage में store करे
• बाद में वही key retrieve हो

इसे एक property में बदलना बहुत direct था:

Round-trip property: किसी भी provider और apiKey के लिए, saveApiKey(provider, apiKey) के बाद loadApiKey(provider) वही value return करे।

ये properties startups के लिए gold हैं क्योंकि:

• ये requirements से सीधे जुड़ती हैं
• ये regression पकड़ती हैं (refactor के बाद भी)
• ये “expected behavior” को executable बनाती हैं

PBT ने क्या किया जो unit tests नहीं कर पाते?

Fast-check जैसी libraries random strings generate करती हैं। और community knowledge की वजह से ये “known nasty strings” भी include करती हैं। 100 runs में 75th run पर provider निकला:

• "__proto__"

और वहीं property fail हो गई।

Unit test authors अक्सर providers के लिए openai, anthropic, azure जैसे realistic values चुनते हैं। attacker realistic नहीं होता।

Failure का root cause: __proto__ और prototype pollution

Answer first: JavaScript में __proto__ एक special accessor है। Normal object पर obj["__proto__"] = ... करने से आप plain key set नहीं कर रहे—आप prototype chain को छेड़ने की कोशिश कर रहे हैं, जो unexpected behavior और security risk बन सकता है।

JavaScript prototype-based language है। इसका मतलब:

• हर object का एक prototype होता है
• property lookup prototype chain से गुजर सकता है

__proto__ historically prototype को read/write करने का hook रहा है। तो जब आप user-controlled string को object key की तरह use करते हैं, और उस string में __proto__ आता है, behavior अलग हो सकता है।

इस case में save करने पर:

• code ने apiKeys[provider] = apiKey किया
• provider था __proto__
• engine ने इसे normal property write की तरह treat नहीं किया
• और load पर expected string नहीं, बल्कि {} जैसा unexpected result मिला

Security angle यहाँ यह है कि prototype manipulation कभी-कभी prototype pollution तक ले जाती है—जहाँ attacker future lookups को poison कर सकता है। भले ही इस exact flow में exploit practical न हो (object short-lived, stringify behavior, scope सीमित), लेकिन ये एक sharp edge है जो future refactor में real vulnerability बन सकती है। Startups में refactors fast होते हैं—इसलिए “unexploitable today” को ignore करना risky है।

Snippet-worthy: Security bugs अक्सर exploitability से पहले correctness bugs की तरह दिखते हैं। PBT आपको exploit बनने से पहले रोक देता है।

Fix: Defensive coding जो requirements के साथ fit बैठे

Answer first: दो छोटे changes—null-prototype object और safe key checks—user-controlled keys को safe बना देते हैं, और future refactors में भी protection रखते हैं।

1) Safe storage: null-prototype object

Normal {} का prototype होता है। Object.create(null) का prototype नहीं होता। यानी __proto__ सिर्फ एक string key बन जाता है—special नहीं।

Approach:

• safe container बनाओ
• existing keys copy करो
• फिर assign करो

इस pattern से prototype pollution का surface drastically reduce होता है, खासकर localStorage + JSON scenarios में।

2) Safe retrieval: hasOwnProperty via call

Direct apiKeys.hasOwnProperty(provider) कई बार fail हो सकता है (अगर attacker hasOwnProperty key inject कर दे)। इसलिए robust तरीका:

• Object.prototype.hasOwnProperty.call(apiKeys, provider)

ये छोटी बात लगती है, लेकिन production security में यही details matter करती हैं।

Startup checklist: इस तरह के bugs से बचने के लिए

1. User-controlled strings को object keys की तरह use कर रहे हैं?
   • providers, headers, query params, form fields—सब count होते हैं
2. Untrusted input को map करना है?
   • plain object की जगह Map consider करें
   • या null-prototype object
3. Serialization/Deserialization boundaries हैं?
   • JSON parse के बाद validation ज़रूरी है
4. Testing strategy में “weird strings” intentional हैं?
   • PBT generators में known bad keys (__proto__, constructor, prototype) जरूर include करें

AI-driven development workflow में PBT कैसे fit करें (practical)

Answer first: PBT को “late-stage QA” मत बनाइए। इसे spec-to-test pipeline का हिस्सा बनाइए—जहाँ properties सीधे acceptance criteria से निकलती हैं।

Startups के लिए workable approach मैंने बार-बार succeed होते देखा है:

Step 1: Requirements को properties में translate करें

Example patterns:

• Round-trip: save → load = same
• Idempotency: operation दो बार करने पर state same
• Monotonicity: count कभी negative नहीं
• Access control: unauthorized user कभी restricted data न देखे

आपका AI assistant (या team) requirements लिखे, और हर requirement के लिए 1-3 properties निकाले।

Step 2: Generators को domain-aware बनाइए

Random strings helpful हैं, लेकिन domain knowledge जोड़ने से quality बढ़ती है:

• provider names: alphanumeric + _ + - + known nasty strings
• API key: realistic prefixes + length constraints
• whitespace, unicode, null bytes जैसी boundary cases

Tip: शुरुआती phase में numRuns 100 रखें। Critical modules के लिए CI nightly में 1,000–10,000 runs चलाइए।

Step 3: Shrinking को debugging tool मानिए

PBT का underrated feature shrinking है। Failure को minimal counterexample में reduce करके ये आपको instantly hint देता है कि bug value में है या key में। इस case में apiKey shrink होकर spaces रह गया—clear signal कि culprit provider name है।

Step 4: Security regression suite बनाइए

Once found, always found. इसका मतलब:

• PBT के साथ-साथ उस exact counterexample को deterministic unit test में pin करें
• ताकि future refactor में failure instantly दिखे

People also ask: “क्या PBT performance slow करेगी?”

Answer first: थोड़ा overhead होता है, लेकिन सही जगह और सही frequency पर run करोगे तो ROI high है—क्योंकि ये bugs production से पहले पकड़ती है।

• Dev loop: 100 runs, fast feedback
• PR checks: 200–500 runs for critical functions
• Nightly: 1,000+ runs + coverage across modules

Most startups over-index on shipping speed and under-index on preventing security debt. PBT आपको दोनों के बीच balance देता है—especially AI-generated code के साथ।

“साइबर सुरक्षा में AI” सीरीज़ के संदर्भ में यह क्यों मायने रखता है

AI security का मतलब सिर्फ SOC automation या threat intel नहीं है। Secure engineering practices—जैसे specification-driven development और property-based testing—भी उसी ecosystem का हिस्सा हैं। क्योंकि AI code generation तभी safe scale करेगा जब verification practices भी upgrade हों।

अगर आप AI-first startup बना रहे हैं (या AI features ship कर रहे हैं), तो मैं एक strong stance लूँगा: PBT को optional quality improvement मत समझिए। इसे security control की तरह treat कीजिए।

Next step simple है: अपने product के किसी एक high-risk flow (auth token storage, billing, permissions, file upload) पर एक round-trip या access-control property लिखिए और 100 runs चलाइए। अगर आपको कोई failure नहीं मिलता—great. अगर मिलता है—आपने production incident avoid कर लिया।

आपके हिसाब से आपकी टीम के codebase में सबसे “attacker-shaped input” कौन सा है: user names, JSON payloads, file names, या provider identifiers?