Claude Code ਸੁਰੱਖਿਆ ਚੈਕਲਿਸਟ ਸਾਡੇ ਤੇਜ਼ ਵੈੱਬ-ਐਪ spot-checks ਲਈ

ਇਕ ਹਲਕਾ-ਫੁਲਕਾ ਸੁਰੱਖਿਆ spot-check ਕੀ ਹੈ

ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਸੁਰੱਖਿਆ spot-check ਇੱਕ ਤੇਜ਼ ਸਮੀਖਿਆ ਹੁੰਦੀ ਹੈ (ਅਕਸਰ 30–60 ਮਿੰਟ) ਜਿਸਦਾ ਮਕਸਦ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਸਪੱਠ, ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਫੜਨਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਪੂਰਾ ਆਡਿਟ ਨਹੀਂ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਸੇਫਟੀ ਵਾਕ-ਥਰੂ ਵਾਂਗ ਸੋਚੋ: ਤੁਸੀਂ ਉਹਨਾਂ ਰਸਤਿਆਂ ਨੂੰ ਸਕੈਨ ਕਰਦੇ ਹੋ ਜੋ ਅਸਲ ਐਪ ਵਿੱਚ ਜ਼ਿਆਦਾ ਵਾਰੀ ਫੇਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਅੰਦਾਜਿਆਂ ਦੀ ਨਹੀਂ, ਪਰ ਸਬੂਤ ਦੀ ਤਲਾਸ਼ ਕਰਦੇ ਹੋ।

ਇਹ Claude Code ਸੁਰੱਖਿਆ ਚੈਕਲਿਸਟ ਉਹ ਖੇਤਰਾਂ ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੈ ਜੋ ਰੋਜ਼ਾਨਾ ਵੈੱਬ ਐਪਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਟੁੱਟਦੇ ਹਨ:

• Authentication ਫਰਜ਼ਾਂ (ਤੁਸੀਂ ਯੂਜ਼ਰ ਨੂੰ ਕਿਵੇਂ ਜਾਣਦੇ ਹੋ)
• Authorization ਖਾਮੀਆਂ (ਉਹ ਕੀ ਕਰ ਸਕਦੇ ਹਨ)
• ਇਨਪੁਟ ਵੈਧਤਾ
• ਸੀਕ੍ਰੇਟ ਹੈਂਡਲਿੰਗ
• ਆਮ ਇੰਜੈਕਸ਼ਨ ਸਤਹ (SQL, ਕਮਾਂਡ ਐਕਜ਼ੈਕਿਊਸ਼ਨ, ਟੈਂਪਲੇਟ ਰੈਂਡਰਿੰਗ, ਰੀਡਾਇਰੈਕਟ, ਅੱਪਲੋਡ)

ਇਹ ਬੱਗਸ ਦੀ ਗੈਰ-ਮੌਜੂਦਗੀ ਨੂੰ ਸਾਬਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦਾ, ਨਾਂ ਹੀ ਜਟਿਲ ਖ਼ਤਰਾ ਐਕਟਰਾਂ ਨੂੰ ਮਾਡਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਨਾਂ ਹੀ penetration testing ਦੀ ਥਾਂ ਲੈਂਦਾ ਹੈ।

“Concrete findings” ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਜੋ ਵੀ ਮੁੱਦਾ ਦਰਜ ਕਰੋ, ਉਸਦਾ ਸਬੂਤ ਹੋਵੇ ਜਿਸ 'ਤੇ ਡਿਵੈਲਪਰ ਤੁਰੰਤ ਕਾਰਵਾਈ ਕਰ ਸਕੇ। ਹਰ findings ਲਈ ਦਰਜ ਕਰੋ:

• 正確 ਫਾਈਲ(ਆਂ) ਅਤੇ ਫੰਕਸ਼ਨ/ਹੈਂਡਲਰ ਦਾ ਨਾਮ
• ਇੱਕ ਵਾਕ ਵਿੱਚ ਖਤਰਨਾਕ ਵਤਾਵਰਣ
• ਇੱਕ ਘੱਟੋ-ਘੱਟ repro ਕਦਮ (request, payload, ਜਾਂ ਕਲਿਕ ਪਾਥ)
• ਇਹ ਕਿਉਂ ਮੈਟਰ ਕਰਦਾ ਹੈ (ਅਸਰ) ਅਤੇ ਕੌਣ ਇਸਨੂੰ ਟਰਿਗਰ ਕਰ ਸਕਦਾ ਹੈ
• ਇੱਕ ਸੁਰੱਖਿਅਤ ਫਿਕਸ ਦਿਸ਼ਾ (ਪੂਰੀ ਰੀਰਾਈਟ ਨਹੀਂ)

AI ਸਹਾਇਕ ਹੈ, ਪ੍ਰਧਾਨ ਨਹੀਂ। ਇਹਨੂੰ ਖੋਜ, ਸਮਰੀ ਅਤੇ ਟੈਸਟ ਸੁਝਾਉਣ ਲਈ ਵਰਤੋ। ਫਿਰ ਕੋਡ ਪੜ੍ਹ ਕੇ ਅਤੇ ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਅਸਲ request ਨਾਲ ਰੀਪ੍ਰੋ ਕਰਕੇ ਤਸਦੀਕ ਕਰੋ। ਜੇ ਮਾਡਲ ਨਿਰਦੇਸ਼ਿਤ ਸਥਾਨ ਅਤੇ ਕਦਮ ਨਹੀਂ ਦੱਸ ਸਕਦਾ, ਤਾਂ ਉਸ ਦਾਅਵੇ ਨੂੰ ਅਣਪ੍ਰਮਾਣਿਤ ਮੰਨੋ।

10 ਮਿੰਟ ਵਿੱਚ ਸਕੋਪ ਤੈਅ ਕਰੋ

ਇੱਕ ਤੇਜ਼ ਸਮੀਖਿਆ ਉਸ ਵੇਲੇ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਲਕੜੀ ਨੂੰ 좁 ਕਰ ਦੋ। Claude Code ਤੋਂ ਕੁਝ ਵੀ ਵੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ ਕਿ ਅੱਜ ਤੁਸੀਂ ਕੀ ਸਾਬਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਕੀ ਨਹੀਂ ਚੈੱਕ ਕਰ ਰਹੇ।

1 ਤੋਂ 3 ਅਸਲ ਯੂਜ਼ਰ ਜਰਨੀਆਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜਿਥੇ ਗਲਤੀ ਪੈਸਾ ਖੋ ਦੇ ਸਕਦੀ ਹੈ, ਡਾਟਾ ਬਾਹਰ ਆ ਸਕਦੀ ਹੈ ਜਾਂ ਸੱਤਾ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਚੰਗੇ ਉਮੀਦਵਾਰ ਹਨ: ਲੌਗਿਨ, ਪਾਸਵਰਡ ਰੀਸੈਟ, ਚੈਕਆਊਟ, ਅਤੇ ਐਡਮਿਨ ਐਡਿਟ ਸਕ੍ਰੀਨ।

ਅਗਲੇ ਕਦਮ ਵਿੱਚ ਉਹ ਐਸੈਟ ਨਾਮ ਲਿਖੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਣਾ ਹੈ। ਸਪਸ਼ਟ ਰਹੋ: ਯੂਜ਼ਰ ਖਾਤੇ, ਭੁਗਤਾਨ ਕਾਰਵਾਈਆਂ, ਨਿੱਜੀ ਡਾਟਾ, ਐਡਮਿਨ-ਕੇਵਲ ਆਪਰੇਸ਼ਨ।

ਫਿਰ ਆਪਣੇ threat assumptions ਸਧਾ ਸ਼ਬਦਾਂ ਵਿੱਚ ਲਿਖੋ। ਕੀ ਤੁਸੀਂ ਇਕ ਜਾਂਚੀ-ਝਾਂਚੀ ਯੂਜ਼ਰ, ਬਾਹਰੀ ਸਕ੍ਰਿਪਟ-ਚਲਾਉਣ ਵਾਲਾ ਹਮਲਾਵਰ, ਜਾਂ ਕੁਝ ਪਹੁੰਚ ਵਾਲੇ ਅੰਦਰੂਨੀ ਵਿਅਕਤੀ ਤੋਂ ਬਚਾ ਰਹੇ ਹੋ? ਤੁਹਾਡਾ ਜਵਾਬ ਇਹ ਬਦਲ ਦੇਵੇਗਾ ਕਿ “ਕਾਫੀ ਚੰਗਾ” ਕੀ ਹੁੰਦਾ ਹੈ।

ਆਖ਼ਿਰਕਾਰ, ਪਾਸ/ਫੇਲ ਨੂੰ ਸਪਸ਼ਟ ਕਰ ਦਿਓ ਤਾਂ ਕਿ ਤੁਹਾਡੀ spot-check findings ਨਾਲ ਖਤਮ ਹੋਏ, ਅਨੁਭਵ ਨਾਲ ਨਹੀਂ। ਸਧਾਰਨ ਨਿਯਮ ਅਕਸਰ ਚੰਗੇ ਰਹਿੰਦੇ ਹਨ:

• Pass: ਹਰ ਸੇਂਸിറ്റਿਵ ਕਾਰਵਾਈ 'ਤੇ ਇੱਕ ਸਪਸ਼ਟ authn ਅਤੇ authz ਚੈੱਕ ਹੋਵੇ।
• Fail: ਕੋਈ ਵੀ endpoint client 'ਤੇ user ID ਜਾਂ ਰੋਲ ਭਰੋਸਾ ਕਰਦਾ ਹੋਵੇ।
• Pass: ਇਨਪુਟ ਸਰਵਰ-ਸਾਈਡ ਤੇ ਵੈਧ ਕੀਤੇ ਜਾਣ, ਸਿਰਫ UI ਤੇ ਨਹੀਂ।
• Fail: ਸੀਕ੍ਰੇਟ ਲੌਗ, configs, ਜਾਂ client ਕੋਡ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ।

ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਵਰਨਾ ਸਕਦੇ ਕਿ ਫੇਲ ਕਿਵੇਂ ਲੱਗੇਗਾ, ਤਾਂ ਸਕੋਪ ਹੋਰ ਵੀ ਢਿਲਾ ਹੈ।

Claude Code ਨੂੰ ਦਿੱਤਾ ਜਾਣ ਵਾਲਾ ਸੰਦਰਭ ਤਿਆਰ ਕਰੋ

ਇੱਕ spot-check ਤਾਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਮਾਡਲ ਸਹੀ ਥਾਵਾਂ ਵੇਖ ਰਿਹਾ ਹੋਵੇ। ਛੋਟਾ ਕੋਡ ਅਤੇ ਨੋਟਾਂ ਦਾ ਇਕ ਬੰਨਲ ਇਕੱਠਾ ਕਰੋ ਤਾਂ ਕਿ ਸਮੀਖਿਆ ਅਨੁਮਾਨ ਨਹੀਂ, ਸਬੂਤ ਪੈਦਾ ਕਰੇ।

ਸੁਰੱਖਿਆ-ਮਹੱਤਵਪੂਰਨ ਪਾਥ ਸਾਂਝੇ ਕਰਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: request ਐਂਟਰੀ ਪੁਇੰਟ ਅਤੇ ਉਹ ਕੋਡ ਜੋ ਨਿਰਣਾ ਕਰਦਾ ਹੈ ਕਿ ਯੂਜ਼ਰ ਕੌਣ ਹੈ ਅਤੇ ਉਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ। ਡੈਟਾ ਫਲੋ ਦਿਖਾਉਣ ਲਈ ਆਸਪਾਸ ਕਾਫੀ ਕੋਡ ਸ਼ਾਮਲ ਕਰੋ।

ਇੱਕ ਵਿਆਵਹਾਰਕ ਬੰਡਲ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ:

• Auth ਐਂਟਰੀ: session/JWT parsing, cookie ਸੈਟਿੰਗਸ, login callbacks, auth middleware
• ਰੂਟ + ਹੈਂਡਲਰ: controllers, RPC methods, GraphQL resolvers, background job handlers
• ਡਾਟਾ ਲੇਅਰ: ORM queries, raw SQL_helpers, query builders, sensitive_tables ਲਈ migrations
• ਪਾਲਿਸੀ ਚੈਕਸ: ਰੋਲ ਚੈਕਸ, ownership ਚੈਕਸ, feature flags, admin-only endpoints
• ਵੈਧਤਾ: request schema validators, file upload handlers, deserialization ਕੋਡ

ਕੁਝ environment ਨੋਟਾਂ ਦੀਆਂ ਲਾਈਨਾਂ ਸ਼ਾਮਿਲ ਕਰੋ ਤਾਂ ਜੋ ਫਰਜ਼ੇ ਸਪਸ਼ਟ ਹੋਣ: session vs JWT, ਟੋਕਨ ਕਿੱਥੇ ਰਹਿੰਦੇ ਹਨ (cookie ਜਾਂ header), reverse proxy ਜਾਂ API gateway ਵਿਹੇਵਿਅਰ, queues/cron workers, ਅਤੇ ਕੋਈ “internal-only” endpoints।

ਬੱਗਾਂ ਦੀ ਤਲਾਸ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ inventory ਮੰਗੋ: ਐਂਟਰੀ ਪੁਇੰਟ, privileged endpoints, ਅਤੇ ਡਾਟਾ ਸਟੋਰ ਜੋ ਛੁਹਣੀ ਗਈਆਂ। ਇਹ surfaces ਛੁੱਟਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਇੱਕ output ਫਾਰਮੈਟ 'ਤੇ ਵੀ ਸਹਿਮਤ ਹੋਵੋ ਜੋ concrete findings ਨੂੰ ਮਜ਼ਬੂਤ ਕਰੇ। ਇੱਕ ਸਧਾਰਨ ਟੇਬਲ ਚੰਗੀ ਰਹਿੰਦੀ ਹੈ: Finding, Severity, Affected endpoint/file, Evidence (ਸਹੀ snippet ਜਾਂ line range), Exploit scenario, Fix suggestion.

30–60 ਮਿੰਟ ਦੀ ਸਮੀਖਿਆ ਲਈ ਕਦਮ-ਦਰ-কਦਮ ਵਰਕਫਲੋ

Timebox ਕਰੋ:

• 10 ਮਿੰਟ orientation ਲਈ
• 15–30 ਮਿੰਟ flows trace ਕਰਨ ਲਈ
• 10 ਮਿੰਟ ਲਿਖਣ ਲਈ

ਮਕਸਦ ਪੂਰਾ ਕਵਰੇਜ ਨਹੀਂ। ਇਹ ਟੈਸਟੇਬਲ findings ਦਾ ਇੱਕ ਛੋਟਾ ਸੈੱਟ ਹੈ।

ਐਪ ਖੁੱਲਾ ਰੱਖੋ ਜਦੋਂ ਤੁਸੀਂ ਕੋਡ ਪੜ੍ਹ ਰਹੇ ਹੋ। UI 'ਤੇ ਕਲਿੱਕ ਕਰੋ ਅਤੇ ਵੇਖੋ ਕਿ ਕਿਹੜੀਆਂ requests ਫਾਇਰ ਹੁੰਦੀਆਂ ਹਨ। ਨੋਟਾਂ ਨੂੰ ਖਾਸ endpoints, parameters, ਅਤੇ ਡਾਟਾ ਸੋਰਸਾਂ ਦੀ ਨਿਸ਼ਾਣੀ ਹੋਵੋ।

ਇੱਕ ਵਰਕਫਲੋ ਜੋ ਇਕ ਹੀ ਬੈਠਕ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦੀ ਹੈ:

1. ਐਂਟਰੀ ਪੁਇੰਟ ਅਤੇ trust boundaries ਦਾ ਸਕੈਚ ਬਣਾਓ। public routes, logged-in routes, admin routes, webhooks, uploads, ਅਤੇ third-party callbacks ਨੂੰ ਨੋਟ ਕਰੋ। ਜਿੱਥੇ ਡਾਟਾ user-controlled ਤੋਂ server-trusted ਵਿੱਚ ਜਾਂਦਾ ਹੈ, ਉਸ ਨੂੰ ਮਾਰਕ ਕਰੋ।
2. ਹਰ ਮਹੱਤਵਪੂਰਨ endpoint ਲਈ ਲਿਖੋ ਕਿ identity ਦਾ ਸਬੂਤ ਕੀ ਹੈ ਅਤੇ ਜਿੱਥੇ ਇਹ ਹੁੰਦਾ ਹੈ। ਜੇ ਚੈੱਕ middleware ਹੈ, ਤਾਂ ਪੱਕਾ ਕਰੋ ਕਿ ਹਰ ਰੂਟ ਵਾਸ਼ਤਵਿਕ ਤੌਰ 'ਤੇ ਇਸਨੂੰ ਵਰਤਦਾ ਹੈ।
3. Authorization ਲਈ ਵੀ ਉਹੀ ਕਰੋ। ਇੱਕ ਖਤਰਨਾਕ ਕਾਰਵਾਈ ਚੁਣੋ (ਦੂਜੇ ਯੂਜ਼ਰ ਦਾ ਡਾਟਾ ਦੇਖਣਾ, ਰੋਲ ਅੱਪਡੇਟ ਕਰਨਾ, export, delete) ਅਤੇ permission ਫੈਸਲਾ ਡੇਟਾਬੇਸ ਕਵੀਰੀ ਤੱਕ ਟਰੇਸ ਕਰੋ।
4. ਯੂਜ਼ਰ ਇਨਪੁਟ ਨੂੰ sinks ਤੱਕ ਟਰੇਸ ਕਰੋ। ਇਕ ਪੈਰਾਮੀਟਰ ਨੂੰ request ਤੋਂ SQL/ORM queries, template rendering, command execution, URL fetches (SSRF), redirects, ਅਤੇ file paths ਤੱਕ ਫਾਲੋ ਕਰੋ।
5. ਟਰੇਸ ਕਰਦੇ ਹੋਏ ਸੈਕ੍ਰੇਟ ਅਤੇ ਕਨਫਿਗ ਫਲੋ ਨੂੰ ਸਕੈਨ ਕਰੋ। ਲੌਗਾਂ ਵਿੱਚ ਟੋਕਨ, client-side ਕੋਡ, error messages, environment dumps, ਅਤੇ ਕਮਜ਼ੋਰ ਸਟੋਰੇਜ ਪੈਟਰਨ ਖੋਜੋ।

ਇੱਕ ਉਪਯੋਗੀ ਆਦਤ: ਹਰ “ਠੀਕ ਲੱਗਦਾ ਹੈ” ਲਈ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਉਸਨੂੰ ਕਿਵੇਂ ਤੋੜੋਗੇ। ਜੇ ਤੁਸੀਂ ਇਕ ਤੋੜਨ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਸੰਭਵ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਵੇਰਫਾਈ ਨਹੀਂ ਕੀਤਾ।

Authn spot-checks: ਯੂਜ਼ਰ ਨੂੰ ਸਾਬਤ ਕਰੋ

Authentication ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਐਪ ਫੈਸਲਾ ਕਰਦੀ ਹੈ, “ਇਹ request ਕਿਸ ਵਿਅਕਤੀ ਦੀ ਹੈ।” ਇਕ ਤੇਜ਼ spot-check ਹਰ ਲਾਈਨ ਪੜ੍ਹਨ ਬਾਰੇ ਨਹੀਂ; ਇਹ identity ਬਣਾਉਣ ਜਾਂ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੀ ਥਾਂ ਲੱਭਣ ਅਤੇ shortcuts ਅਤੇ failure paths ਦੀ ਜਾਂਚ ਕਰਨ ਬਾਰੇ ਹੈ।

trust boundary ਲੱਭੋ: identity ਪਹਿਲਾਂ ਕਿੱਥੇ ਬਣਦੀ ਜਾਂ ਮਨਜ਼ੂਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ? ਇਹ session cookie, JWT bearer token, API key, ਜਾਂ edge ਤੇ mTLS ਹੋ ਸਕਦਾ ਹੈ। Claude Code ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਹ ਠੀਕ ਫਾਈਲ ਅਤੇ ਫੰਕਸ਼ਨ ਦੱਸੇ ਜੋ “anonymous” ਨੂੰ user id ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਹਰ ਹੋਰ ਰਾਹ ਜੋ ਇਹ ਕਰ ਸਕਦਾ ਹੈ ਦੀ ਸੂਚੀ ਦਿਵਾਓ।

Authn ਚੈੱਕ ਜੋ ਸਕੈਨ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ:

• ਸਾਰੇ auth ਐਂਟਰੀ ਪੁਇੰਟ (web login, API tokens, mobile auth, internal service auth) ਨੂੰ ਪਛਾਣੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਉਹ ਇੱਕ ਸੰਗਤ identity ਮਾਡਲ ਤੇ ਮਿਲਦੇ ਹਨ।
• ਲੌਗਿਨ ਅਤੇ ਪਾਸਵਰਡ ਰੀਸੈਟ ਲਈ rate limits, lockouts, ਅਤੇ user enumeration (ਮੌਜੂਦਾ vs ਗੈਰ-ਮੌਜੂਦਾ ਖਾਤਿਆਂ ਲਈ ਵੱਖ-ਵੱਖ error messages ਜਾਂ timing) ਦੀ ਜਾਂਚ ਕਰੋ।
• ਸੈਸ਼ਨ ਅਤੇ ਕੁਕੀਜ਼ ਦੀ ਜਾਂਚ ਕਰੋ: HttpOnly, Secure, SameSite, expiry, login ਤੇ rotation ਅਤੇ privilege change 'ਤੇ rotation, ਅਤੇ logout invalidation (ਸਰਵਰ-ਸਾਈਡ, ਨਾ ਕਿ ਸਿਰਫ “cookie ਹਟਾਓ”)।
• MFA ਅਤੇ recovery ਰਾਹ ਦੇਖੋ ਤਾਂ ਜੋ recovery ਪਾਥ MFA ਨਾਲੋਂ ਕਮਜ਼ੋਰ ਨਾ ਹੋਵੇ (ਉਦਾਹਰਨ: email-only reset ਜੋ MFA ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਦੇਵੇ)।
• auth failure logging ਦੀ ਸਮੀਖਿਆ ਕਰੋ: ops ਲਈ ਲਾਭਦਾਇਕ ਹੈ, ਪਰ ਐਸਾ ਕੁਝ leak ਨਾ ਕਰੋ ਜੋ ਹਮਲਾਵਰ ਦੀ ਮਦਦ ਕਰੇ (ਕੋਈ “user exists” hints, ਕੋਈ token dumps ਨਹੀਂ)।

ਵਿਆਹੀ ਉਦਾਹਰਨ: ਜੇ reset emails “account not found” ਵਾਪਸ ਕਰਦੇ ਹਨ, ਤਾਂ ਇਹ ਇੱਕ ਤੇਜ਼ enumeration ਮੁੱਦਾ ਹੈ। generic message ਹੋਣ ਦੇ ਬਾਵਜੂਦ timing ਅੰਤਰ ਵੀ ਉਹੀ ਸੂਚਨਾ ਲੀਕ ਕਰ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ response timing ਵੀ spot-check ਕਰੋ।

Authz spot-checks: ਯੂਜ਼ਰ ਨੂੰ ਅਧਿਕਾਰ ਦਿਖਾਓ

Authorization ਕਰਨ ਵਾਲਾ ਸਵਾਲ ਹੈ ਜੋ ਗਲਤ ਹੋਣ 'ਤੇ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਨੁਕਸਾਨ ਕਰਦਾ ਹੈ: “ਕੀ ਇਹ ਯੂਜ਼ਰ ਇਹ ਕਾਰਵਾਈ ਇਸ ਖ਼ਾਸ ਸਰੋਤ ਤੇ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਰੱਖਦਾ ਹੈ?” ਤੇਜ਼ spot-check ਖ਼ੁਦ-ਮੁਖਤਾਰ ਤਰੀਕੇ ਨਾਲ ਉਸ ਧਾਰਨਾ ਨੂੰ ਤੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇ।

ਰੋਲਾਂ ਅਤੇ permissions ਨੂੰ ਸਧੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਲਿਖੋ। ਇਸਨੂੰ ਮਨੁੱਖ-ਪਠਣਯੋਗ ਰੱਖੋ:

• Owner ਮੈਂਬਰਾਂ ਨੂੰ ਨਿਯੁਕਤ ਕਰ ਸਕਦਾ ਹੈ
• Member ਆਪਣਾ ਪ੍ਰੋਫਾਇਲ ਸੋਧ ਸਕਦਾ ਹੈ
• Support ਬਿਲਿੰਗ ਵੇਰਵੇ ਦੇਖ ਸਕਦਾ ਹੈ ਪਰ ਯੋਜਨਾ ਨਹੀਂ ਬਦਲ ਸਕਦਾ
• Admin ਪ੍ਰੋਜੈਕਟ ਮਿਟਾ ਸਕਦਾ ਹੈ

ਫਿਰ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਹਰ ਸੇਂਸਿਟਿਵ ਕਾਰਵਾਈ ਸਰਵਰ 'ਤੇ authz ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਸਿਰਫ UI 'ਚ ਨਹੀਂ। ਬਟਨਾਂ ਨੂੰ ਛੁਪਾਇਆ ਜਾਂ ਸਕਦਾ ਹੈ, ਕਲਾਇੰਟ ਰੂਟ ਰੁਕ ਸਕਦੇ ਹਨ, ਪਰ ਹਮਲਾਵਰ ਐਪੀਆਈ ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ।

ਇੱਕ ਤੇਜ਼ ਸਕੈਨ ਜੋ ਅਕਸਰ ਅਸਲ ਮੁੱਦੇ ਲੱਭਦਾ:

• endpoints/mutations ਲੱਭੋ ਜੋ create, delete, export, role change, ਜਾਂ billing access ਕਰਦੇ ਹਨ
• ਹਰ ਇਕ ਲਈ ਸਰਵਰ-ਸਾਈਡ permission check ਲੱਭੋ (ਫਰੰਟਐਂਡ ਨਹੀਂ)
• user-controlled IDs (projectId, userId, orgId) ਲਈ ownership checks ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ
• ਯਕੀਨੀ ਬਣਾਓ admin-only paths role ਮਿਸ਼ਪ ਹੋਣ 'ਤੇ fail close ਕਰਦੇ ਹਨ
• tenant ਸੀਮਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰੋ: orgId/accountId session context ਤੋਂ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਿਰਫ request input ਤੋਂ ਨਹੀਂ

ਆਮ IDOR ਦੀ ਗੰਧ ਸਧਾਰਨ ਹੁੰਦੀ ਹੈ: ਇੱਕ request ਵਰਗਾ GET /projects/{id} ਜਿੱਥੇ {id} user-controlled ਹੈ, ਅਤੇ ਸਰਵਰ ਇਸਨੂੰ ਲੋਡ ਕਰਦਾ ਹੈ ਬਿਨਾਂ ਇਹ ਸਾਬਤ ਕੀਤੇ ਕਿ ਇਹ current user ਜਾਂ tenant ਨਾਲ ਮਿਲਦਾ ਹੈ।

ਇੱਕ ਪ੍ਰੈਂਪਟ ਜੋ ਅਸਲ ਜਵਾਬ ਮਜ਼ਬੂਰ ਕਰਦਾ ਹੈ:

"ਇਸ endpoint ਲਈ, ਪੁਸ਼ਟ ਕਰੋ ਉਹੀਕੋਡ ਜੋ ਐਕਸੈਸ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਖਾਸ ਸ਼ਰਤਾਂ ਲਿਖੋ ਜਿਹੜੀਆਂ ਕਿਸੇ ਹੋਰ orgId ਦੇ ਯੂਜ਼ਰ ਨੂੰ ਇਸ ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਆਗਿਆ ਦੇਣਗੀਆਂ। ਜੇ ਨਹੀਂ, ਤਾਂ ਫਾਇਲ ਅਤੇ ਫੰਕਸ਼ਨ ਨਾਂਮ ਨਾਲ ਸਮਝਾਓ ਕਿਉਂ ਨਹੀਂ।"

ਇਨਪੁੱਟ ਵੈਧਤਾ: ਗਲਤ ਡਾਟਾ ਨੂੰ ਜਲਦੀ ਰੋਕੋ

ਜ਼ਿਆਦਾਤਰ ਤੇਜ਼ ਵੈੱਬ ਐਪ ਮੁੱਦੇ ਇੱਕ ਖਾਲੀਪਣ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ: ਐਪ ਉਮੀਦ ਨਾ ਕਰਨ ਵਾਲੀ ਇਨਪੁੱਟ ਨੂੰ ਮੰਨ ਲੈਂਦਾ ਹੈ। “ਇਨਪੁੱਟ” ਨੂੰ ਕੁਝ ਵੀ ਮੰਨੋ ਜੋ ਯੂਜ਼ਰ ਜਾਂ ਹੋਰ ਸਿਸਟਮ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੇ ਹਨ, ਭਾਵੇਂ ਇਹ ਹਲਕਾ ਲੱਗੇ।

ਉਸ endpoint ਲਈ ਇਨਪੁੱਟਾਂ ਨੂੰ ਨਾਮ ਦੇ ਕੇ ਸ਼ੁਰੂ ਕਰੋ ਜਿਸਦੀ ਤੁਸੀਂ spot-check ਕਰ ਰਹੇ ਹੋ:

• URL query ਅਤੇ path ਮੁੱਲ
• Request body ਫੀਲਡ (ਨੈਸਟਡ JSON ਸਮੇਤ)
• Headers (auth headers, content type, forwarded IP)
• Cookies
• File uploads (ਨਾਂ, ਸਾਈਜ਼, ਟਾਈਪ, ਮੈਟਾ ਡੇਟਾ)

ਵੈਧਤਾ ਓਥੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿੱਥੇ ਡਾਟਾ ਐਪ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਕਾਰੋਬਾਰੀ ਲਾਜਿਕ ਦੇ ਅੰਦਰ। ਬੇਸਿਕ ਚੀਜ਼ਾਂ ਦੀ ਜਾਂਚ ਕਰੋ: type (string vs number), max length, required vs optional, ਅਤੇ format (email, UUID, date)।

ਰੋਲ, status ਫੀਲਡ, ਜਾਂ sort directions ਵਰਗੀਆਂ ਜਾਣਿਆ ਮੁੱਲਾਂ ਲਈ allowlist ਵਰਤੋ। ਇਹ “ਕੁਝ ਖਰਾਬ ਮੁੱਲ ਰੋਕੋ” ਨਾਲੋਂ ਬਚਾਉਂਦਾ ਹੈ।

ਤਦ error handling ਦੀ ਵੀ ਜਾਂਚ ਕਰੋ। ਜੇ ਐਪ ਇਨਪੁੱਟ ਨੂੰreject ਕਰਦੀ ਹੈ, ਤਾਂ raw value ਨੂੰ response, logs, ਜਾਂ UI ਵਿੱਚ ਵਾਪਸ ਨਾ ਦਿਖਾਓ। ਇਹੋ ਹੀ ਛੋਟੀ validation bugs ਡਾਟਾ leaks ਜਾਂ ਇੰਜੈਕਸ਼ਨ ਸਹਾਇਕ ਬਣ ਜਾਂਦੀਆਂ ਹਨ।

ਖਤਰਨਾਕ endpoints (login, search, upload, admin actions) ਲਈ ਇੱਕ ਛੋਟਾ “ਖਰਾਬ ਇਨਪੁੱਟ” ਯੋਜਨਾ:

• ਬਹੁਤ ਲੰਬੇ strings (10,000+ chars)
• ਗਲਤ types (string ਦੀ ਥਾਂ array)
• ਅਪੇਖਿਤ enum ਮੁੱਲ
• ਖਾਸ ਅੱਖਰ ਜੋ ਮਤਲਬ ਬਦਲ ਸਕਦੇ ਹਨ
• Required ਫੀਲਡ ਲਈ ਖਾਲੀ ਮੁੱਲ

ਉਦਾਹਰਨ: ਇੱਕ sort ਪੈਰਾਮੀਟਰ ਜੋ ਕਿਸੇ ਵੀ string ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ SQL fragment ਬਣ ਸਕਦਾ ਹੈ। ਇੱਕ allowlist ਜਿਵੇਂ "date" ਜਾਂ "price" ਇਸ ਜਾਤ ਦੀ ਗਲਤੀ ਨੂੰ ਪਹਿਲੇ ਪੜਾਅ 'ਤੇ ਰੋਕਦਾ ਹੈ।

ਆਮ ਇੰਜੈਕਸ਼ਨ ਸਤਹ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਸਕੈਨ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ

ਜ਼ਿਆਦਾਤਰ ਤੇਜ਼ ਸਮੀਖਿਆਉਂ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਵਹੀ ਥਾਵਾਂ 'ਤੇ ਮਿਲਦੀਆਂ ਹਨ: ਜਿੱਥੇ ਵੀ ਯੂਜ਼ਰ ਇਨਪੁੱਟ ਨੂੰ ਕੋਡ, ਕੂਐਰੀ, ਪਾਥ ਜਾਂ URL ਵਾਂਗ интерਪ੍ਰੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਭਾਗ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ “ਇਨਪੁੱਟ ਵTrust boundary ਨੂੰ ਪਾਰ ਕਰਦਾ ਹੈ” ਘੜਕੇ ਖੋਜ ਕਰਦੇ ਹੋ।

ਐਂਟਰੀ ਪੁਇੰਟ (query params, headers, cookies, uploads, admin forms) ਤੋਂ ਡਾਟਾ ਉਥੇ ਜਿੱਥੇ ਇਹ ਖਤਰਨਾਕ ਹੁੰਦਾ ਹੈ ਤੱਕ ਟਰੇਸ ਕਰੋ।

ਤੇਜ਼ ਸਕੈਨ ਟਾਰਗੇਟ

ਇਹ ਪੈਟਰਨ ਖੋਜੋ ਅਤੇ ਹਰ ਇੱਕ ਲਈ concrete call site ਅਤੇ payload ਉਦਾਹਰਨ ਦੀ ਮੰਗ ਕਰੋ:

• SQL injection: string-built queries, dynamic ORDER BY, ਅਤੇ IN (...) ਨਿਰਮਾਤਾ ਜੋ user values ਨੂੰ join ਕਰਦੇ ਹਨ
• XSS: HTML ਰੈਂਡਰਿੰਗ, templates, markdown previews, rich text editors ਜਿੱਥੇ “sanitize later” ਮੰਨਿਆ ਗਿਆ ਹੋਵੇ
• Command injection: image processing, PDF tools, backups, ਜਾਂ "convert" ਕਦਮ ਜੋ user-controlled flags ਪਾਸ ਕਰਦੇ ਹਨ
• SSRF: URL fetchers ਲਈ webhooks, link previews, import-from-URL ਫੀਚਰ, ਅਤੇ internal status checks ਜੋ ਯੂਜ਼ਰ URL ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ
• Path traversal: file download endpoints, zip extraction, ਅਤੇ upload pipelines ਜੋ ਬਾਅਦ ਵਿੱਚ ਨਾਮ ਨਾਲ ਫਾਈਲਾਂ ਪੜ੍ਹਦੇ ਹਨ

deserialization ਅਤੇ template injection ਲਈ ਵੀ ਧਿਆਨ ਰੱਖੋ। ਜੇ ਕੋਈ ਫੀਚਰ ਯੂਜ਼ਰ-ਪ੍ਰਦਾਨ JSON, YAML, ਜਾਂ templated strings ਨੂੰ parse ਕਰਦਾ ਹੈ ਤਾਂ ਉਹ ਖਤਰਨਾਕ ਰਹਿ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜੇ ਇਸਨੂੰ custom types, expressions, ਜਾਂ server-side rendering ਸਮਰਥਨ ਮਿਲਿਆ ਹੋਵੇ।

ਜੇ ਕੋਈ ਫੀਚਰ URL, filename, ਜਾਂ formatted text ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਮੰਨੋ ਕਿ ਇਹ ਦੁਪਹਿਰ ਤੱਕ ਦੁਰਪਯੋਗ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਕੋਡ ਰਾਹਾਂ ਅਤੇ ਟੈਸਟ ਨਾਲ ਇਸਨੂੰ ਸਾਬਤ ਨਹੀਂ ਕਰਦੇ।

ਸੀਕ੍ਰੇਟ ਹੈਂਡਲਿੰਗ: ਲੀਕ ਅਤੇ ਕਮਜ਼ੋਰ ਸਟੋਰੇਜ ਲੱਭੋ

ਸੀਕ੍ਰੇਟ ਸਮੱਸਿਆਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਉੱਚ-ਧੁਨੀ ਹੁੰਦੀਆਂ ਹਨ ਜਦ ਤੁਸੀਂ ਪਤਾ ਲਗਾ ਲੈਂਦੇ ਹੋ ਕਿ ਥਾਂ ਕਿੱਥੇ ਹਨ। ਧਿਆਨ ਇਸ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਕਰੋ ਕਿ ਸੀਕ੍ਰੇਟ ਕਿੱਥੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਕਿੱਥੇ ਅਕਸਮਾਤੀ ਕਾਪੀ ਹੋ ਰਹੇ ਹਨ।

ਆਮ ਥਾਵਾਂ ਜਿੱਥੇ ਸੀਕ੍ਰੇਟ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ:

• Environment variables ਅਤੇ app config files
• CI output ਅਤੇ build logs (ਫੇਲ ਹੋਏ deploy logs ਸਮੇਤ)
• Client bundles ਅਤੇ mobile builds (ਜਿਹੜੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਭੇਜੇ ਜਾਂਦੇ ਹਨ)
• Debug endpoints, health pages, ਅਤੇ admin tools
• Error pages, stack traces, ਅਤੇ analytics events

ਫਿਰ ਇੱਕ concrete ਸਵਾਲ ਪੁੱਛੋ: ਜੇ ਅੱਜ ਕੋਈ ਸੀਕ੍ਰੇਟ ਪ੍ਰਗਟ ਹੋ ਗਿਆ, ਤਾਂ ਅਗਲਾ ਕਦਮ ਕੀ ਹੋਵੇਗਾ? ਇੱਕ ਚੰਗੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ rotation (ਨਵਾਂ key ਜਾਰੀ), revocation (ਪੁਰਾਣਾ key disabled), ਅਤੇ ਫਟਾਫਟ redeploy ਕਰਨ ਦਾ ਰਾਸਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਜਵਾਬ "ਬਾਅਦ ਵਿੱਚ ਬਦਲਾਂਗੇ" ਹੈ, ਤਾਂ ਇਸਨੂੰ finding ਮੰਨੋ।

Least privilege ਵੀ ਇੱਕ ਤੇਜ਼ ਫਾਇਦਾ ਹੈ। ਕੀਜ਼ ਜ਼ਿਆਦਾ 권限 ਵਾਲੇ ਹੋਣ ਨਾਲ incidents ਵੱਡੇ ਬਣਦੇ ਹਨ। DB ਯੂਜ਼ਰ ਜੋ tables ਡ੍ਰਾਪ ਕਰ ਸਕਦੇ ਹਨ, third-party tokens ਜੋ accounts manage ਕਰ ਸਕਦੇ ਹਨ, ਜਾਂ API keys ਜੋ environments ਵਾਰ ਸਾਂਝੇ ਕੀਤੇ ਗਏ ਹਨ ਨੂੰ ਲੱਭੋ। ਇੱਕ-ਕੀ ਪਰ ਸੇਵਾ, ਪਰ environmenਤ, ਅਤੇ ਸਭ ਤੋਂ ਛੋਟੇ 권限 ਪREFER ਕਰੋ।

ਤੇਜ਼ spot-check ਪ੍ਰੈਂਪਟ ਜਿਹੜੇ ਤੁਸੀਂ Claude Code ਵਿੱਚ ਪੇਸਟ ਕਰ ਸਕਦੇ ਹੋ:

• “Hard-coded tokens, passwords, ਅਤੇ private keys ਲਈ repo ਖੋਜੋ। ਸਹੀ file paths ਅਤੇ string patterns ਜਿਹੜੀਆਂ ਮਿਲੀਆਂ ਉਹ ਲਿਖੋ।”
• “ਕੋਈ ਕੋਡ ਜੋ request headers, cookies, env vars, ਜਾਂ ਫੁੱਲ error objects ਲੌਗ ਕਰਦਾ ਹੈ, ਲੱਭੋ। ਲੌਗ ਲਾਈਨਾਂ ਦਿਖਾਓ ਅਤੇ ਕਿਹੜੀਆਂ حساس ਫੀਲਡਜ਼ ਉਥੇ ਆ ਸਕਦੀਆਂ ਹਨ।”
• “ਚੈੱਕ ਕਰੋ ਕਿ ਸੀਕ੍ਰੇਟ snapshots, exports, ਜਾਂ build artifacts ਵਿੱਚ ਪੈ ਸਕਦੇ ਹਨ। ਕੀ ਕੈਪਚਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕਿੱਥੇ ਸਟੋਰ ਹੁੰਦਾ ਹੈ ਉਸ ਦੀ ਪਛਾਣ ਕਰੋ।”

ਅਖੀਰ ਵਿੱਚ, guardrails ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: source control ਤੋਂ ਸੀਕ੍ਰੇਟ ਰੋਕੋ (pre-commit/CI checks), ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ backups ਜਾਂ snapshots plain-text credentials ਨਹੀਂ ਰੱਖਦੇ। ਜੇ ਤੁਸੀਂแพਲੈਟਫਾਰਮ snapshots ਅਤੇ rollback ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ ਤਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੀਕ੍ਰੇਟ runtime ਤੇ inject ਹੁੰਦੇ ਹਨ, ਬੇਕਡ ਇਮੇਜ ਵਿੱਚ ਨਹੀਂ।

ਜੋ ਪ੍ਰੈਂਪਟ concrete findings 'ਤੇ ਮਜ਼ਬੂਰ ਕਰਨ

ਧੁੰਦਲੇ ਪ੍ਰੈਂਪਟ ਧੁੰਦਲੇ ਜਵਾਬ ਲੈਂਦੇ ਹਨ। ਮਾਡਲ ਨੂੰ ਸਭੂਤ 'ਤੇ ਕਮਟ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰੋ: ਸਹੀ ਸਥਾਨ, ਤੁਸੀਂ ਫਾਲੋ ਕਰ ਸਕਦੇ ਟਰੇਸ, ਇੱਕ ਰੀਪ੍ਰੋ ਜੋ ਤੁਸੀਂ ਚਲਾਂਗੇ, ਅਤੇ ਕੀ ਚੀਜ਼ ਦਾਅਵਾ ਨੂੰ ਗਲਤ ਸਿੱਧ ਕਰੇਗੀ।

ਇੱਕ-ਇੱਕ ਪੈਟਰਨ ਵਰਤੋ, ਫਿਰ ਪੁੱਛੋ ਕਿ ਉਸ ਨੇ ਤਸਦੀਕੀ ਜਾਂ ਨਵੇਂ ਵੇਰਵੇ ਮਿਲਣ 'ਤੇ ਪੁਰਾ ਕੀ ਵਧਾਵੇ।

• ਫਾਈਲ-ਪੱਧਰੀ ਸਬੂਤ: “repo ਵਿੱਚ auth, sessions, tokens, ਅਤੇ middleware ਲਈ ਖੋਜ ਕਰੋ। ਠੀਕ ਫਾਈਲਾਂ, ਫੰਕਸ਼ਨਾਂ, ਅਤੇ line ranges ਨਾਮ ਦਿਓ। ਪ੍ਰਸੰਗਿਕ snippets quote ਕਰੋ। ਜੇ ਤੁਸੀਂ ਕੋਡ ਨੂੰ ਪੁਆਇੰਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਕਹੋ ‘no evidence found’।”
• ਇਨਪੁੱਟ ਤੋਂ ਸਿੰਕ ਤੱਕ ਟਰੇਸ: “ਇੱਕ user-controlled ਇਨਪੁੱਟ ਚੁਣੋ (header, query, body, cookie). ਐਂਟਰੀ ਪੁਇੰਟ ਤੋਂ ਜਿੱਥੇ ਇਹ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ (SQL, HTML, shell, template, redirect, file path) ਤੱਕ ਡੇਟਾ ਫਲੋ ਕਦਮ-ਦਰ-কਦਮ ਦਿਖਾਓ। ਹਰ ਫੰਕਸ਼ਨ ਦੀ ਸੂਚੀ ਦਿਓ।”
• ਰੀਪ੍ਰੋ ਸਭੰਧੀ ਕਦਮ: “ਇੱਕ ਘੱਟੋ-ਘੱਟ repro curl ਨਾਲ ਦਿਓ (method, URL shape, headers, body). ਉਮਮੀਦ ਕੀਤੀ status code ਅਤੇ success/failure response ਉਦਾਹਰਨ ਸ਼ਾਮਿਲ ਕਰੋ। ਧਾਰਨਾਵਾਂ ਦਿਓ (roles, auth state)।”
• False-positive ਨਿਯੰਤਰਣ: “ਇਹ finding ਨੂੰ ਗਲਤ ਸਾਬਤ ਕਰਨ ਲਈ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ? 2–3 checks ਲਿਖੋ: config flags, middleware order, allowlist validation, parameterized queries, framework escaping. ਜੇ ਕੋਈ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਸਮਝਾਓ ਕਿ risk ਕਿਵੇਂ ਬਦਲਦਾ ਹੈ।”
• ਸਭ ਤੋਂ ਛੋਟਾ ਸੁਰੱਖਿਅਤ ਫਿਕਸ + ਟੈਸਟ: “ਉਹੋ ਛੋਟਾ ਬਦਲਾਅ ਸੁਝਾਓ ਜੋ ਮੁੱਦੇ ਨੂੰ ਰੋਕੇ ਬਿਨਾਂ ਵੈਧ ਕੇਸ ਟੋੜੇ। ਫਿਰ ਇੱਕ ਟੈਸਟ ਲਿਖੋ ਜੋ ਜੋੜਨਾ ਹੈ (ਨਾਮ, ਨੀਅਤ, ਇਨਪੁੱਟ, ਉਮੀਦਤ ਨਤੀजा)। ਜੇ ਕੋਈ tradeoffs ਹਨ, ਉਹ ਵੀ ਸਪਸ਼ਟ ਕਰੋ।”

ਜੇ ਆਉਟਪੁੱਟ ਹੁਣ ਵੀ ਧੁੰਦਲਾ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਕਨਦੀ ਕਰੋ:

“ਸਿਰਫ਼ ਇਹਨਾਂ ਨਾਲ ਜਵਾਬ ਦਿਓ: file path, function name, risky line, ਅਤੇ ਇੱਕ-ਵਾਕ ਦਾ impact।”

ਇੱਕ ਵਾਸਤਵਿਕ ਉਦਾਹਰਨ: ਅਨੁਮਾਨ ਨੂੰ ਇੱਕ ਪੁਸ਼ਟੀ ਕੀਤੀ ਸਮੱਸਿਆ ਵਿੱਚ ਬਦਲਣਾ

Profile update endpoints ਅਕਸਰ access control bugs ਛੁਪਾਉਂਦੇ ਹਨ। ਹੇਠਾਂ ਇੱਕ ਛੋਟਾ ਕੇਸ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਇਸ ਚੈਕਲਿਸਟ ਨਾਲ ਚਲਾ ਸਕਦੇ ਹੋ।

ਸਥਿਤੀ: ਇੱਕ API endpoint user profile ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ:

PATCH /api/profile?accountId=123 JSON ਨਾਲ { "displayName": "Sam" }.

ਤੁਸੀਂ Claude Code ਨੂੰ handler ਲੱਭਣ, accountId ਦੇ ਉਪਯੋਗ ਨੂੰ ਟਰੇਸ ਕਰਨ, ਅਤੇ ਸਾਬਤ ਕਰਨ ਲਈ ਪੁੱਛਦੇ ਹੋ ਕਿ ਸਰਵਰ ownership ਲਾਗੂ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਅਕਸਰ ਜੋ ਮਿਲਦਾ ਹੈ:

• Authn: request session ਜਾਂ token ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਲੁੱਕ ਕਰਕੇ ਸੁਰੱਖਿਅਤ ਲੱਗਦਾ ਹੈ।
• Authz: handler query string ਤੋਂ accountId 'ਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸ account ਨੂੰ ਓਹਲੇ ਬਿਨਾਂ ਚੈੱਕ ਕੀਤਾ ਅਪਡੇਟ ਕਰ ਦਿੰਦਾ ਹੈ ਕਿ ਇਹ logged-in user ਦਾ ਹੈ।
• Input validation: displayName trim ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ accountId ਨੂੰ integer ਵਜੋਂ validate ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ।
• Injection surface: SQL string concatenation ਵਰਗਾ "... WHERE account_id=" + accountId ਵਰਤਿਆ ਗਿਆ ਹੈ।

ਇੱਕ ਚੰਗਾ write-up concrete ਹੁੰਦਾ ਹੈ:

• Severity: High (IDOR + ਸੰਭਵ SQL injection)
• Evidence: ਇੱਕ ਵੈਧ ਲੌਗਿਨ ਨਾਲ request ਹੋਰ ਯੂਜ਼ਰ ਨੂੰ ਬਦਲਦਾ ਹੈ ਜਦੋਂ accountId ਤਬਦੀਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ; SQL ਅਣ-ਭਰੋਸੇਯੋਗ ਇਨਪੁੱਟ ਤੋਂ ਬਣਾਇਆ ਜਾ ਰਿਹਾ ਹੈ
• Fix: client ਤੋਂ accountId ਨੂੰ ਅਣਦੇਖਾ ਕਰੋ; ਸਰਵਰ-ਸਾਈਡ ਤੇ authenticated ਯੂਜ਼ਰ ਦਾ account id ਵਰਤੋ; query ਨੂੰ parameterize ਕਰੋ
• Test: ਦੂਜੇ account ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਅਤੇ 403 ਦੀ ਉਮੀਦ ਰੱਖੋ; non-numeric accountId ਨੂੰ reject ਕਰੋ

ਪੈਚ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੇਜ਼ੀ ਨਾਲ ਦੁਬਾਰਾ-ਚੈੱਕ ਕਰੋ:

• ਵੱਖਰਾ accountId ਨਾਲ ਉਹੀ request ਫਿਰ_try ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਫੇਲ ਹੁੰਦੀ ਹੈ।
• ਲੌਗਾਂ ਨੂੰ ਦਿਖਾਓ ਕਿ ਸਰਵਰ authenticated id ਵਰਤਦਾ ਹੈ, ਨਾ ਕਿ query param।
• ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ query placeholders/params ਵਰਤ ਰਿਹਾ ਹੈ, ਨਾ ਕਿ string building।
• malformed input ਲਈ ਇੱਕ negative test ਚਲਾਓ (ਅੱਖਰ, ਬਹੁਤ ਵੱਡਾ ਨੰਬਰ)।

ਆਮ ਜਾਲ ਜੋ spot-checks ਨੂੰ ਅਸਲ ਮੁੱਦਿਆਂ ਤੋਂ ਵੱਖ ਕਰ ਦਿੰਦੇ ਹਨ

ਸਭ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ vulnerability ਨੂੰ ਨਾਂ ਦੇਖਣ ਦਾ ਤਰੀਕਾ UI ਤੇ ਜੋ enforcement ਜਾਪਦਾ ਹੈ ਉਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਹੈ। ਇੱਕ ਬਟਨ ਜੋ ਲੁਕਿਆ ਜਾਂ disabled ਹੈ permission check ਨਹੀਂ ਹੈ। ਜੇ ਸਰਵਰ request ਨੂੰ ਫਿਰ ਵੀ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਕੋਈ ਵੀ ਇਹਨਾਂ ਨੂੰ ਦੁਹਰਾ ਕੇ ਵੱਖ user ID, ਵੱਖ ਰੋਲ, ਜਾਂ ਸਿੱਧਾ API call ਨਾਲ ਕਰ ਸਕਦਾ ਹੈ।

ਹੋਰ ਇੱਕ ਆਮ ਖ਼ਮੀ ਇਹ ਹੈ ਕਿ ਪ੍ਰਸ਼ਨ ਬਹੁਤ vague ਦਿੱਤਾ ਗਿਆ ਹੋਵੇ। “ਇੱਕ ਸੁਰੱਖਿਆ ਸਮੀਖਿਆ ਕਰੋ” ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਜਨਰਿਕ ਰਿਪੋਰਟ ਦਿੰਦਾ ਹੈ। ਇੱਕ spot-check ਨੂੰ ਤੰਗ ਸਕੋਪ (ਕਿਹੜੇ endpoints, ਕਿਹੜੇ roles, ਕਿਹੜਾ ਡਾਟਾ) ਅਤੇ ਇਕ ਸਖ਼ਤ output ਫਾਰਮੈਟ (file name, function, risky line, minimal repro) ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

AI ਆਉਟਪੁੱਟ ਲਈ ਉਹੀ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਜੇ finding concrete code location ਅਤੇ trigger ਦੇ ਕਦਮ ਬਿਨਾਂ ਨਹੀਂ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਅਣ-ਪ੍ਰਮਾਣਿਤ ਮੰਨੋ।

ਤੇਜ਼ ਰਸਤੇ ਜਿਨ੍ਹਾਂ 'ਤੇ spot-checks ਗਲਤ ਹੋ ਜਾਂਦੇ ਹਨ

ਇਹ ਫੰਦੇ ਵਾਰ-ਵਾਰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ:

• ਇਹ ਸਮਝਣਾ ਕਿ "admin-only" ਹੈ ਕਿਉਂਕਿ ਇਹ admin ਪੇਜ ਹੈ, ਨਾ ਕਿ ਇਸ ਲਈ ਕਿ ਸਰਵਰ ਇਸਨੂੰ enforce ਕਰਦਾ ਹੈ
• "ਬ੍ਰਾਡ ਰਿਵਿਊ ਦੇ ਨਤੀਜੇ" ਦੀ ਜਗ੍ਹਾ "ਉਸ X ਨੂੰ bypass ਕਰਨ ਵਾਲਾ ਠੀਕ ਰਿਕਵੇਸਟ ਦਿਖਾਓ" ਪੁੱਛਣਾ
• "ਸੰਭਵ SQL injection" ਨੂੰ query ਨਿਰਮਾਣ ਬਿੰਦੂ ਅਤੇ input path ਬਿਨਾਂ ਸਵੀਕਾਰ ਕਰ ਲੈਣਾ
• webhook, scheduled jobs, import tools, ਅਤੇ internal admin actions ਵਰਗੇ ਘੱਟ ਸਪਸ਼ਟ ਐਂਟਰੀ ਪੁਇੰਟ ਛੱਡਣਾ
• ਲੱਛਣਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਬਜਾਏ ਸਿੰਬਟਮਸ ਨੂੰ ਪੈਚ ਕਰਨਾ (regex ਜਾਂ ਫਿਲਟਰ ਜੋ ਜੋੜ-ਜੋੜ ਕਰਦੇ ਰਹਿਣ)

ਜੇ ਤੁਸੀਂ ਹਰ ਨਵੇਂ edge case ਤੋਂ ਬਾਅਦ ਹੋਰ ਫਿਲਟਰ ਜੋੜਦੇ ਹੋ, ਰੁਕੋ। ਫਿਕਸ ਆਮ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਅਤੇ ਸਧਾਰਨ ਹੁੰਦਾ ਹੈ: ਬਾਊਂਡਰੀ ਤੇ ਇਨਪੁੱਟ validate ਕਰੋ, ਅਤੇ authorization checks ਨੂੰ explicit ਅਤੇ ਕੇਂਦਰਤ ਬਣਾਓ ਤਾਂ ਕਿ ਹਰ ਕੋਡ ਪਾਥ ਉਹਨਾਂ ਨੂੰ ਵਰਤੇ।

ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਸੀਂ ਚਲਾ ਸਕਦੇ ਕੁਝ ਤੇਜ਼ ਚੈੱਕ

ਇਹ ਪੂਰੇ ਰਿਵਿਊ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੇ, ਪਰ ਉਹ ਗਲਤੀਆਂ ਫੜ ਲੈਂਦੇ ਹਨ ਜੋ ਥੱਕੇ ਹੋਏ ਸਮੇਂ ਵਿੱਚ ਛੁੱਟ ਜਾਂਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਸਬੂਤ-ਮੁੱਖੀ ਰੱਖੋ: ਇੱਕ request ਜੋ ਤੁਸੀਂ ਭੇਜ ਸਕੋ, ਇੱਕ ਪੇਜ ਜੋ ਤੁਸੀਂ ਲੋਡ ਕਰ ਸਕੋ, ਜਾਂ ਇੱਕ ਲੌਗ ਲਾਈਨ ਜੋ ਤੁਸੀਂ ਲੱਭ ਸਕੋ।

ਪੰਜ ਤੇਜ਼ spot-checks ਜੋ ਅਕਸਰ ਫੈਦੇਮੰਦ ਸਾਬਤ ਹੁੰਦੇ ਹਨ:

• Authn friction: 10 ਗਲਤ ਲੌਗਿਨ ลੜੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਕੀ rate limits, lockouts, ਜਾਂ ਘੱਟੋ-ਘੱਟ slowdown ਦੇਖਦੇ ਹੋ? ਕੀ ਤੁਸੀਂ error messages ਜਾਂ timing ਤੋਂ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਇੱਕ email ਮੌਜੂਦ ਹੈ?
• Authz by ID swap: ਇੱਕ ਅਸਲ resource (order, invoice, profile) ਚੁਣੋ। URL, JSON body, ਜਾਂ GraphQL variables ਵਿੱਚ ID ਬਦਲੋ। ਕੀ ਤੁਹਾਨੂੰ ਕੋਈ ਅਜਿਹਾ ਡਾਟਾ ਮਿਲਦਾ ਹੈ ਜੋ ਤੁਹਾਡਾ ਨਹੀਂ, ਭਲੇ ਹੀ ਉਹ "ਸਿਰਫ਼ metadata" ਹੋਵੇ?
• Input guardrails: ਮੁੱਖ ਫੀਲਡਾਂ (email, name, search, file upload) ਲਈ ਬਹੁਤ ਲੰਬੇ strings, عجیب Unicode, ਅਤੇ ਗਲਤ types (number ਬਜਾਏ string) ਅਜ਼ਮਾਓ। ਕੀ ਤੁਸੀਂ length limits ਅਤੇ allowlists ਲਾਗੂ ਕਰਦੇ ਹੋ ਜਿੱਥੇ ਜ਼ਰੂਰੀ ਹਨ?
• Secrets exposure: ਹਾਲੀਆ logs ਅਤੇ client bundles ਵਿੱਚ tokens, API keys, JWTs, ਜਾਂ "Authorization: Bearer" ਖੋਜੋ। error pages ਵੀ ਚੈੱਕ ਕਰੋ। "Sirf staging ਵਿੱਚ ਸੀ" ਅਕਸਰ "ਇਹ shipped ਹੋ ਗਿਆ" ਬਣ ਜਾਂਦਾ ਹੈ।
• Injection surfaces: SQL, filters, template rendering, shell commands, ਜਾਂ redirect URLs ਵਿੱਚ string concatenation ਲੱਭੋ। ਜੇ ਇਨਪੁੱਟ ਇਨ੍ਹਾਂ ਤਕ ਜਾਂਦਾ ਹੈ ਬਿਨਾਂ ਮਜ਼ਬੂਤ validation ਦੇ, ਤਾਂ ਜੋਖਿਮ ਮੰਨ ਲਓ।

ਅਗਲੇ ਹਫ਼ਤੇ ਲਈ ਉਹ 3 ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਫਿਕਸ ਲਿਖੋ ਜਿਹੜੇ ਤੁਸੀਂ ਸ਼ਿਪ ਕਰ ਸਕੋ, ਨਾ ਕਿ ਇਕ ਇੱਛਾ-ਸੂਚੀ। ਉਦਾਹਰਨ: (1) login ਅਤੇ password reset 'ਤੇ rate limiting ਸ਼ਾਮਿਲ ਕਰੋ, (2) "get by id" endpoint 'ਤੇ ਸਰਵਰ-ਸਾਈਡ ownership checks ਲਾਗੂ ਕਰੋ, (3) search field ਲਈ input length cap ਅਤੇ ਅਣ-ਅਪੇਖਿਤ ਅੱਖਰ ਰੱਦ ਕਰੋ।

ਅਗਲੇ ਕਦਮ: ਇਸ ਚੈਕਲਿਸਟ ਨੂੰ ਆਪਣੇ build process ਦਾ ਹਿੱਸਾ ਬਣਾਓ

ਇੱਕ spot-check ਫਾਇਦਾ ਦਿੰਦੀ ਹੈ ਜੇ نتائج ਉਹਨਾਂ ਨੂੰ ship ਹੋਣ 'ਤੇ ਬਦਲਣ। ਇਸ ਚੈਕਲਿਸਟ ਨੂੰ ਇੱਕ ਛੋਟੇ, ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ build ਕਦਮ ਵਜੋਂ ਸੋਚੋ, ਇੱਕ ਵਾਰ ਦੀ ਮਦਦ ਦੀ ਤਰ੍ਹਾਂ ਨਹੀਂ।

ਹਰ finding ਨੂੰ ਇੱਕ backlog ਆਈਟਮ ਬਣਾਓ ਜੋ ਸਮਝਣ ਵਿੱਚ ਮੁਸ਼ਕਲ ਨਾ ਹੋਵੇ:

• Fix: ਕੋਡ ਜਾਂ config ਵਿੱਚ ਕੀ ਬਦਲੇਗਾ
• Test: ਇਹ ਕਿਵੇਂ ਸਾਬਤ ਕੀਤਾ ਜਾਵੇਗਾ (ਇੱਕ request, ਇੱਕ ਯੂਨਿਟ ਟੈਸਟ, ਇੱਕ QA ਕਦਮ)
• Owner: ਇੱਕ ਜਿੰਮੇਵਾਰ ਵਿਅਕਤੀ
• Target date: ਅਗਲੀ ਰਿਲੀਜ਼ ਜਾਂ ਇੱਕ ਨਿਰਧਾਰਿਤ ਦਿਨ
• Evidence: file/endpoint ਅਤੇ ਉਹੀ ਸਹੀ request ਜਾਂ payload ਜੋ ਮੁੱਦਾ ਦਿਖਾਇਆ

ਜਿੰਨੇ ਤੇਜ਼ ਹੋ ਸਕੇ ਉਸ cadence ਨੂੰ ਚੁਣੋ। ਬਹੁਤੀਆਂ ਟੀਮਾਂ ਲਈ ਹਰ ਰਿਲੀਜ਼ ਸਭ ਤੋਂ ਵਧੀਆ ਹੁੰਦੀ ਹੈ। ਜੇ ਰਿਲੀਜ਼ ਬਹੁਤ ਅਕਸਰ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਮਹੀਨੇਵਾਰ 30–60 ਮਿੰਟ ਸਮੀਖਿਆ ਅਤੇ ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਕ ਛੋਟਾ ਚੈੱਕ ਕਰੋ।

ਇਸਨੂੰ ਦੁਹਰਾਉਣਾ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਇੱਕ reusable prompt pack ਅਤੇ ਚੈਕਲਿਸਟ ਟੈਂਪਲੇਟ ਬਣਾਓ। ਪ੍ਰੈਂਪਟ concrete ਆਉਟਪੁੱਟ ਤੇ ਕੇਂਦ੍ਰਿਤ ਰakho: route ਦਿਖਾਓ, guard ਦਿਖਾਓ, failing request ਅਤੇ ਉਮੀਦਤ ਵਿਹੇਵਾਰ। pack ਨੂੰ ਜਿੱਥੇ ਟੀਮ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰਦੀ ਹੈ ਉੱਥੇ ਰੱਖੋ ਤਾਂ ਕਿ ਇਹ ਛੱਡਿਆ ਨਾ ਜਾਵੇ।

ਜੇ ਤੁਸੀਂ chat ਰਾਹੀਂ ਐਪ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ planning ਵਿੱਚ ਇਹ ਚੈਕਲਿਸਟ ਸ਼ਾਮਿਲ ਕਰੋ। authn/authz, inputs, ਅਤੇ secrets ਲਈ ਇੱਕ ਛੋਟਾ "security assumptions" ਨੋਟ ਜੋੜੋ, ਫਿਰ ਪਹਿਲੀ ਕੰਮਕਾਜ ਿਵਰਜ਼ਨ ਦੇ ਤੁਰੰਤ ਬਾਅਦ spot-check ਚਲਾਓ।

Platforms like Koder.ai (koder.ai) ਇਸ ਆਦਤ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਹੋ ਸਕਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ iterate ਕਰਨ ਦਿੰਦੇ ਹਨ ਅਤੇ review checkpoints ਰੱਖਦੇ ਹਨ। risky changes ਦੇ ਆਲੇ-ਦੁਆਲੇ snapshots ਅਤੇ rollback ਵਰਤ ਕੇ security fixes ship ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣਾ ਸੌਖਾ ਹੁੰਦਾ ਹੈ।