AI ਨਾਲ ਬਣੀਆਂ ਐਪਾਂ ਲਈ ਸੁਰੱਖਿਆ ਚੈੱਕਲਿਸਟ: ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਜਾਂਚਣਾ ਹੈ

ਅਸਲ ਲੋਕਾਂ ਦੇ ਵਰਤਣ ਤੋਂ ਪਹਿਲਾਂ, AI ਨਾਲ ਬਣੀ ਐਪ ਵਿੱਚ ਸੱਤ ਗੱਲਾਂ ਜਾਂਚੋ: ਹਰ ਪੰਨਾ ਅਤੇ ਹਰ API ਜਾਂਚੇ ਕਿ ਵਰਤੋਂਕਾਰ ਕੌਣ ਹੈ ਅਤੇ ਉਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ; ਸੀਕ੍ਰੇਟ ਕੀਜ਼ ਸਰਵਰ 'ਤੇ ਰਹਿਣ, ਬਰਾਊਜ਼ਰ ਜਾਂ ਚੈਟ ਵਿੱਚ ਕਦੇ ਨਹੀਂ; ਸਾਰਾ ਇਨਪੁੱਟ ਸਰਵਰ 'ਤੇ ਜਾਂਚਿਆ ਜਾਵੇ; ਹਰ ਵਰਤੋਂਕਾਰ ਸਿਰਫ਼ ਆਪਣੇ ਰਿਕਾਰਡ ਤੱਕ ਪਹੁੰਚ ਸਕੇ; ਲੌਗ-ਇਨ ਅਤੇ ਮਹਿੰਗੇ ਐਂਡਪੌਇੰਟਾਂ 'ਤੇ ਰੇਟ ਲਿਮਿਟ ਹੋਵੇ; ਡਿਪੈਂਡੈਂਸੀਆਂ ਅੱਪ ਟੂ ਡੇਟ ਹੋਣ; ਅਤੇ ਕੁਝ ਗ਼ਲਤ ਹੋਣ 'ਤੇ ਤੁਸੀਂ ਡੇਟਾ ਵਾਪਸ ਲਿਆ ਸਕੋ। ਹੇਠਾਂ ਦੀ ਚੈੱਕਲਿਸਟ ਹਰ ਗੱਲ ਨੂੰ ਖ਼ਾਸ ਟੈਸਟਾਂ ਵਿੱਚ ਬਦਲਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਕੋਡ ਪੜ੍ਹੇ ਬਿਨਾਂ ਕਰ ਸਕਦੇ ਹੋ।

AI ਐਪ ਬਿਲਡਰ ਫੀਚਰ ਕੰਮ ਕਰਵਾਉਣ ਵਿੱਚ ਚੰਗੇ ਹਨ। ਉਹ ਆਪਣੇ ਆਪ ਸਾਵਧਾਨ ਨਹੀਂ ਹੁੰਦੇ, ਕਿਉਂਕਿ "ਸਾਵਧਾਨੀ" ਸ਼ਾਇਦ ਹੀ ਪ੍ਰੋਮਪਟ ਵਿੱਚ ਹੁੰਦੀ ਹੈ। ਹੇਠਾਂ ਦੀਆਂ ਜ਼ਿਆਦਾਤਰ ਸਮੱਸਿਆਵਾਂ ਉਹਨਾਂ ਗੱਲਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਕਿਸੇ ਨੇ ਮੰਗੀਆਂ ਨਹੀਂ ਸਨ, ਇਸ ਲਈ ਹੱਲ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਹੈ ਕਿ ਮੰਗ ਲਓ।

ਇਹ ਚੈੱਕਲਿਸਟ ਕਿਵੇਂ ਵਰਤੀਏ

ਇਸਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਪੂਰਾ ਕਰੋ, ਅਤੇ ਹਰ ਆਈਟਮ ਲਈ ਦੋ ਕੰਮ ਕਰੋ: AI ਨੂੰ ਪੁੱਛੋ ਕਿ ਇਹ ਸੰਭਾਲਿਆ ਜਾਵੇ, ਅਤੇ ਆਪ ਟੈਸਟ ਕਰੋ। AI ਇਜਾਜ਼ਤ ਜਾਂਚ ਲਿਖ ਸਕਦਾ ਹੈ; ਕੇਵਲ ਟੈਸਟ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਕੰਮ ਕਰਦੀ ਹੈ। ਆਈਟਮਾਂ ਇਸ ਤਰ੍ਹਾਂ ਚਿੰਨ੍ਹਿਤ ਹਨ:

• Must — ਕਿਸੇ ਹੋਰ ਦੇ ਐਪ ਵਰਤਣ ਤੋਂ ਪਹਿਲਾਂ ਕਰੋ।
• Should — ਅਸਲ ਵਰਤੋਂਕਾਰ ਜਾਂ ਅਸਲ ਡੇਟਾ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਕਰੋ।
• Later — ਐਪ ਵਧਣ ਦੇ ਨਾਲ ਕਰਨ ਯੋਗ।

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਇੱਕ ਘੰਟਾ ਹੈ, ਤਾਂ ਹਰ Must ਕਰੋ।

1. ਪ੍ਰਮਾਣਿਕਤਾ: ਇਹ ਕੌਣ ਹੈ?

ਪ੍ਰਮਾਣਿਕਤਾ (authentication) ਦਾ ਮਤਲਬ ਹੈ ਇਹ ਪੱਕਾ ਕਰਨਾ ਕਿ ਕੋਈ ਕੌਣ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਲੌਗ-ਇਨ। ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਲਈ ਪ੍ਰਮਾਣਿਕਤਾ ਕੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਵਿਕਲਪਾਂ ਲਈ ਆਪਣੀ ਐਪ ਵਿੱਚ ਲੌਗ-ਇਨ ਕਿਵੇਂ ਜੋੜੀਏ ਵੇਖੋ।

• Must: ਹਰ ਪੰਨਾ ਜੋ ਨਿੱਜੀ ਡੇਟਾ ਦਿਖਾਉਂਦਾ ਹੈ ਲੌਗ-ਇਨ ਮੰਗੇ। ਟੈਸਟ: ਲੌਗ ਆਉਟ ਕਰੋ, ਫਿਰ ਕਿਸੇ ਨਿੱਜੀ ਪੰਨੇ ਦਾ URL ਸਿੱਧਾ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਪੇਸਟ ਕਰੋ।
• Must: ਉਨ੍ਹਾਂ ਪੰਨਿਆਂ ਦੇ ਪਿੱਛੇ ਹਰ API ਐਂਡਪੌਇੰਟ ਵੀ ਲੌਗ-ਇਨ ਮੰਗੇ, ਸਿਰਫ਼ ਪੰਨਾ ਨਹੀਂ। ਟੈਸਟ: ਲੌਗ ਆਉਟ ਕਰੋ, ਬਰਾਊਜ਼ਰ ਦੇ ਨੈੱਟਵਰਕ ਟੈਬ ਵਿੱਚ ਉਹ ਬੇਨਤੀ ਦੁਬਾਰਾ ਭੇਜੋ ਜੋ ਐਪ ਨੇ ਲੌਗ-ਇਨ ਹੋਣ ਵੇਲੇ ਕੀਤੀ ਸੀ।
• Must: ਪਾਸਵਰਡ ਹੈਸ਼ ਕਰਕੇ ਇੱਕ ਹੌਲੀ ਪਾਸਵਰਡ-ਹੈਸ਼ਿੰਗ ਐਲਗੋਰਿਦਮ ਨਾਲ ਸਟੋਰ ਹੋਣ, ਕਦੇ ਸਾਦੇ ਟੈਕਸਟ ਵਿੱਚ ਨਹੀਂ। OWASP ਦੀ ਪਾਸਵਰਡ ਸਟੋਰੇਜ ਗਾਈਡ Argon2id ਨੂੰ ਪਹਿਲਾਂ ਸੁਝਾਉਂਦੀ ਹੈ, ਅਤੇ ਵਿਕਲਪ ਵਜੋਂ scrypt, bcrypt ਜਾਂ PBKDF2। ਪੁੱਛੋ: "ਪਾਸਵਰਡ ਕਿਵੇਂ ਸਟੋਰ ਹੁੰਦੇ ਹਨ?"
• Should: ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਲਿੰਕ ਮਿਆਦ ਖ਼ਤਮ ਹੋਣ ਵਾਲੇ ਹੋਣ ਅਤੇ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਕੰਮ ਕਰਨ।
• Should: ਸੈਸ਼ਨ ਕੂਕੀਜ਼ Secure, HttpOnly ਅਤੇ SameSite ਨਾਲ ਚਿੰਨ੍ਹਿਤ ਹੋਣ, ਅਤੇ ਲੌਗ ਆਉਟ ਕਰਨ ਨਾਲ ਸਰਵਰ 'ਤੇ ਸੈਸ਼ਨ ਖ਼ਤਮ ਹੋਵੇ।
• Later: ਟੂ-ਫੈਕਟਰ ਪ੍ਰਮਾਣਿਕਤਾ ਦਿਓ, ਜਾਂ ਉਸ ਪ੍ਰਦਾਤਾ ਰਾਹੀਂ ਸਾਈਨ-ਇਨ ਜੋ ਇਹ ਦਿੰਦਾ ਹੈ।

ਹਰ API ਰੂਟ ਅਤੇ ਪੰਨਾ ਜਾਂਚੋ ਜੋ ਵਰਤੋਂਕਾਰ ਦਾ ਡੇਟਾ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਹਰ ਇੱਕ ਨੂੰ ਲੌਗ-ਇਨ ਨਾ ਹੋਏ ਵਰਤੋਂਕਾਰਾਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਰੱਦ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਪੰਨੇ ਦੇ ਕੋਡ ਵਿੱਚ ਹੀ ਨਹੀਂ, ਸਰਵਰ 'ਤੇ। ਜਾਂਚੇ ਗਏ ਰੂਟਾਂ ਦੀ ਸੂਚੀ ਦਿਓ।

2. ਅਧਿਕਾਰ: ਉਨ੍ਹਾਂ ਨੂੰ ਕੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ?

ਅਧਿਕਾਰ (authorization) ਲੌਗ-ਇਨ ਤੋਂ ਬਾਅਦ ਦਾ ਕਦਮ ਹੈ: ਇਹ ਤੈਅ ਕਰਨਾ ਕਿ ਇਹ ਖ਼ਾਸ ਵਰਤੋਂਕਾਰ ਕੀ ਦੇਖ ਅਤੇ ਬਦਲ ਸਕਦਾ ਹੈ। AI ਨਾਲ ਬਣੀਆਂ ਐਪਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਗੰਭੀਰ ਛੇਕ ਅਕਸਰ ਇੱਥੇ ਹੁੰਦੇ ਹਨ, ਕਿਉਂਕਿ ਐਪ ਸਹੀ ਦਿਸਦੀ ਹੈ: ਹਰ ਵਰਤੋਂਕਾਰ ਦਾ ਡੈਸ਼ਬੋਰਡ ਸਿਰਫ਼ ਉਸਦਾ ਡੇਟਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਜਦਕਿ ਸਰਵਰ ਸਿੱਧੀ ਮੰਗ 'ਤੇ ਕਿਸੇ ਦਾ ਵੀ ਡੇਟਾ ਦੇ ਦਿੰਦਾ ਹੈ।

• Must: ਹਰ ਪੜ੍ਹਨ, ਅਪਡੇਟ ਅਤੇ ਮਿਟਾਉਣ ਦੀ ਕਾਰਵਾਈ ਸਰਵਰ 'ਤੇ ਜਾਂਚੇ ਕਿ ਰਿਕਾਰਡ ਮੌਜੂਦਾ ਵਰਤੋਂਕਾਰ (ਜਾਂ ਉਸਦੀ ਟੀਮ) ਦਾ ਹੈ।
• Must: ਟੈਸਟ ਕਰੋ: ਦੋ ਅਕਾਊਂਟ ਬਣਾਓ, A ਅਤੇ B। A ਵਜੋਂ A ਦਾ ਕੋਈ ਰਿਕਾਰਡ ਖੋਲ੍ਹੋ ਅਤੇ URL ਜਾਂ ਨੈੱਟਵਰਕ ਬੇਨਤੀ ਵਿੱਚ ID ਨੋਟ ਕਰੋ। B ਵਜੋਂ ਲੌਗ-ਇਨ ਕਰਕੇ ਉਹੀ ID ਮੰਗੋ। B ਨੂੰ ਗ਼ਲਤੀ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ, A ਦਾ ਡੇਟਾ ਨਹੀਂ।
• Must: ਐਡਮਿਨ ਪੰਨੇ ਅਤੇ ਐਡਮਿਨ API ਐਂਡਪੌਇੰਟ ਸਰਵਰ 'ਤੇ ਵਰਤੋਂਕਾਰ ਦੀ ਭੂਮਿਕਾ ਜਾਂਚਣ। ਐਡਮਿਨ ਲਿੰਕ ਲੁਕਾਉਣਾ ਸੁਰੱਖਿਆ ਨਹੀਂ ਹੈ।
• Must: ਵਰਤੋਂਕਾਰ ਬੇਨਤੀ ਬਦਲ ਕੇ ਆਪਣੀ ਭੂਮਿਕਾ, ਕੀਮਤ, ਬਕਾਇਆ ਜਾਂ ਮਾਲਕ ਵਾਲੇ ਖੇਤਰ ਨਾ ਬਦਲ ਸਕਣ। ਟੈਸਟ: ਨੈੱਟਵਰਕ ਟੈਬ ਵਿੱਚ ਦੇਖੋ ਕਿ ਪ੍ਰੋਫਾਈਲ ਅਪਡੇਟ ਕੀ ਭੇਜਦਾ ਹੈ। ਜੇ ਇਸ ਵਿੱਚ role ਜਾਂ isAdmin ਵਰਗੇ ਖੇਤਰ ਹਨ, ਤਾਂ AI ਨੂੰ ਕਹੋ ਕਿ ਇਹ ਕਲਾਇੰਟ ਤੋਂ ਨਾ ਮੰਨੇ।
• Should: URL ਵਿੱਚ ID ਅੰਦਾਜ਼ਾ ਲਾਉਣੇ ਔਖੇ ਹੋਣ (1, 2, 3 ਦੀ ਥਾਂ ਰੈਂਡਮ ID)। ਇਹ ਇਜਾਜ਼ਤ ਜਾਂਚ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ, ਪਰ ਜਦੋਂ ਇਹ ਗ਼ਾਇਬ ਹੋਵੇ ਤਾਂ ਨੁਕਸਾਨ ਸੀਮਤ ਕਰਦਾ ਹੈ।

ਹਰ ਐਂਡਪੌਇੰਟ ਲਈ ਜੋ ਰਿਕਾਰਡ ਪੜ੍ਹਦਾ ਜਾਂ ਬਦਲਦਾ ਹੈ, ਸਰਵਰ 'ਤੇ ਜਾਂਚੋ ਕਿ ਲੌਗ-ਇਨ ਵਰਤੋਂਕਾਰ ਇਸਦਾ ਮਾਲਕ ਹੈ ਜਾਂ ਇਸ ਤੱਕ ਪਹੁੰਚ ਦਾ ਹੱਕਦਾਰ ਹੈ। ਨਾ ਹੋਣ 'ਤੇ 404 ਦਿਓ। ਫਿਰ ਦੱਸੋ ਕਿ ਦੋ ਅਕਾਊਂਟਾਂ ਨਾਲ ਇਸਨੂੰ ਕਿਵੇਂ ਟੈਸਟ ਕਰਾਂਗੇ।

3. ਡੇਟਾਬੇਸ ਵਿੱਚ ਰੋ-ਪੱਧਰ ਦੀ ਪਹੁੰਚ

"ਰੋ-ਪੱਧਰ ਦੀ ਪਹੁੰਚ" ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟੇਬਲ ਦੀ ਹਰ ਰੋ (ਇੱਕ ਬੁਕਿੰਗ, ਇੱਕ ਇਨਵੌਇਸ) ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਦਕਿਸੇ ਜਿਨ੍ਹਾਂ ਦੀ ਉਹ ਹੈ। ਇਸਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਦੋ ਆਮ ਤਰੀਕੇ ਹਨ:

ਦੋਵੇਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਜੋ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ:

• Must: ਜੇ ਬਰਾਊਜ਼ਰ ਡੇਟਾਬੇਸ ਨਾਲ ਸਿੱਧਾ ਗੱਲ ਕਰਦਾ ਹੈ (ਕੁਝ ਹੋਸਟਡ ਡੇਟਾਬੇਸ ਉਤਪਾਦ ਇਹ ਦਿੰਦੇ ਹਨ), ਤਾਂ ਹਰ ਟੇਬਲ ਲਈ ਰੋ-ਪੱਧਰ ਨਿਯਮ ਚਾਲੂ ਹੋਣ। ਇਨ੍ਹਾਂ ਤੋਂ ਬਿਨਾਂ, ਪਬਲਿਕ ਕੀ ਵਾਲਾ ਕੋਈ ਵੀ ਪੂਰੀ ਟੇਬਲ ਪੜ੍ਹ ਸਕਦਾ ਹੈ।
• Must: ਕਵੇਰੀਆਂ ਮੌਜੂਦਾ ਵਰਤੋਂਕਾਰ ਜਾਂ ਟੀਮ ਨਾਲ ਫਿਲਟਰ ਹੋਣ, ਬਰਾਊਜ਼ਰ ਵੱਲੋਂ ਭੇਜੀ ID ਨਾਲ ਨਹੀਂ।
• Should: ਸਾਂਝਾ ਡੇਟਾ (ਟੀਮ ਦੇ ਪ੍ਰੋਜੈਕਟ) ਲਈ ਇਹ ਸਾਫ਼ ਨਿਯਮ ਹੋਵੇ ਕਿ ਟੀਮ ਵਿੱਚ ਕੌਣ ਹੈ, ਅਤੇ ਇਹ ਇੱਕੋ ਥਾਂ 'ਤੇ ਲਾਗੂ ਹੋਵੇ।

4. ਸੀਕ੍ਰੇਟ ਅਤੇ API ਕੀਜ਼

API ਕੀ ਇੱਕ ਸੇਵਾ ਲਈ ਪਾਸਵਰਡ ਹੈ। Stripe, ਈਮੇਲ ਅਤੇ AI ਪ੍ਰਦਾਤਾ ਸਾਰੇ ਇਨ੍ਹਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਪਿਛੋਕੜ ਲਈ ਵੇਖੋ ਐਨਵਾਇਰਮੈਂਟ ਵੇਰੀਏਬਲ ਅਤੇ ਸੀਕ੍ਰੇਟ ਕੀ ਹੁੰਦੇ ਹਨ।

• Must: ਕੀਜ਼ ਪ੍ਰੋਜੈਕਟ ਦੇ ਐਨਵਾਇਰਮੈਂਟ ਵੇਰੀਏਬਲ ਜਾਂ ਸੀਕ੍ਰੇਟਸ ਵਿੱਚ ਰੱਖੀਆਂ ਜਾਣ, ਕਦੇ ਕੋਡ ਵਿੱਚ ਨਹੀਂ ਲਿਖੀਆਂ।
• Must: ਜਿਹੜੀਆਂ ਕੀਜ਼ ਪੈਸੇ ਖ਼ਰਚ ਸਕਦੀਆਂ ਹਨ ਜਾਂ ਨਿੱਜੀ ਡੇਟਾ ਪੜ੍ਹ ਸਕਦੀਆਂ ਹਨ, ਉਹ ਸਿਰਫ਼ ਸਰਵਰ 'ਤੇ ਵਰਤੀਆਂ ਜਾਣ। ਟੈਸਟ: ਆਪਣੀ ਲਾਈਵ ਸਾਈਟ ਖੋਲ੍ਹੋ, ਪੇਜ ਸੋਰਸ ਅਤੇ JavaScript ਫਾਈਲਾਂ ਡਿਵੈਲਪਰ ਟੂਲਾਂ ਵਿੱਚ ਦੇਖੋ, ਅਤੇ ਆਪਣੀ ਕੀ ਦੀ ਸ਼ੁਰੂਆਤ ਲੱਭੋ (ਜਿਵੇਂ sk_)। ਇਹ ਉੱਥੇ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।
• Must: ਕੀਜ਼ ਕਦੇ ਚੈਟ, ਜਨਤਕ ਰਿਪੋਜ਼ਟਰੀ ਜਾਂ ਸਕਰੀਨਸ਼ਾਟ ਵਿੱਚ ਪੇਸਟ ਨਾ ਹੋਣ। ਜੇ ਹੋਈਆਂ ਹਨ, ਤਾਂ ਪ੍ਰਦਾਤਾ 'ਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਬਦਲੋ (ਨਵੀਂ ਬਣਾਓ, ਪੁਰਾਣੀ ਮਿਟਾਓ)।
• Should: ਜਿੱਥੇ ਪ੍ਰਦਾਤਾ ਦਿੰਦਾ ਹੈ, ਸੀਮਤ ਜਾਂ ਸਕੋਪ ਵਾਲੀਆਂ ਕੀਜ਼ ਵਰਤੋ। ਉਦਾਹਰਣ ਲਈ, Stripe ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਇਜਾਜ਼ਤਾਂ ਵਾਲੀਆਂ ਸੀਮਤ ਕੀਜ਼ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਹਾਡੇ ਏਕੀਕਰਨ ਨੂੰ ਲੋੜ ਹੈ।
• Should: ਟੈਸਟ ਅਤੇ ਲਾਈਵ ਕੀਜ਼ ਵੱਖਰੀਆਂ ਹੋਣ, ਅਤੇ ਲਾਈਵ ਐਪ ਲਾਈਵ ਕੀਜ਼ ਤਦ ਹੀ ਵਰਤੇ ਜਦੋਂ ਤੁਸੀਂ ਤਿਆਰ ਹੋ।

ਕੁਝ ਕੀਜ਼ ਜਨਤਕ ਹੋਣ ਲਈ ਬਣਾਈਆਂ ਗਈਆਂ ਹਨ, ਜਿਵੇਂ Stripe ਦੀ publishable ਕੀ (pk_…) ਜਾਂ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਡੋਮੇਨ ਤੱਕ ਸੀਮਤ ਮੈਪਸ ਕੀ। ਨਿਯਮ ਉਨ੍ਹਾਂ ਕੀਜ਼ ਬਾਰੇ ਹੈ ਜੋ ਤਾਕਤ ਦਿੰਦੀਆਂ ਹਨ, ਹਰ ਉਸ ਸਤਰ ਬਾਰੇ ਨਹੀਂ ਜੋ ਕੀ ਵਰਗੀ ਲੱਗੇ।

5. ਇਨਪੁੱਟ ਜਾਂਚ

ਵਰਤੋਂਕਾਰ ਜੋ ਵੀ ਭੇਜਦਾ ਹੈ (ਫਾਰਮ ਖੇਤਰ, ਫਾਈਲ ਅੱਪਲੋਡ, URL ਪੈਰਾਮੀਟਰ), ਉਹ ਕੁਝ ਵੀ ਹੋ ਸਕਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਉਹ ਜੋ ਤੁਹਾਡਾ ਫਾਰਮ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

• Must: ਜਾਂਚ ਸਰਵਰ 'ਤੇ ਹੋਵੇ, ਸਿਰਫ਼ ਬਰਾਊਜ਼ਰ ਵਿੱਚ ਨਹੀਂ। ਬਰਾਊਜ਼ਰ ਦੀਆਂ ਜਾਂਚਾਂ ਸਹੂਲਤ ਲਈ ਹਨ; ਕੋਈ ਵੀ ਉਨ੍ਹਾਂ ਨੂੰ ਛੱਡ ਸਕਦਾ ਹੈ।
• Must: ਡੇਟਾਬੇਸ ਕਵੇਰੀਆਂ ਪੈਰਾਮੀਟਰ ਵਰਤਣ, ਵਰਤੋਂਕਾਰ ਦੇ ਇਨਪੁੱਟ ਤੋਂ ਜੋੜੇ ਟੈਕਸਟ ਨਾਲ ਨਹੀਂ (ਇਹ SQL ਇੰਜੈਕਸ਼ਨ ਰੋਕਦਾ ਹੈ)। AI ਤੋਂ ਪੁਸ਼ਟੀ ਕਰਵਾਓ।
• Must: ਵਰਤੋਂਕਾਰ ਵੱਲੋਂ ਲਿਖਿਆ ਟੈਕਸਟ ਟੈਕਸਟ ਵਜੋਂ ਦਿਖੇ, HTML ਵਜੋਂ ਨਾ ਚੱਲੇ। ਟੈਸਟ: ਆਪਣੇ ਨਾਮ ਵਜੋਂ <b>hello</b> ਲਿਖੋ। ਤੁਹਾਨੂੰ ਟੈਗ ਦਿਸਣੇ ਚਾਹੀਦੇ ਹਨ, ਬੋਲਡ ਟੈਕਸਟ ਨਹੀਂ।
• Should: ਫਾਈਲ ਅੱਪਲੋਡ ਕਿਸਮ ਅਤੇ ਆਕਾਰ ਜਾਂਚਣ, ਅਤੇ ਅੱਪਲੋਡ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਤੁਹਾਡੇ ਐਪ ਦੇ ਮੁੱਖ ਡੋਮੇਨ ਤੋਂ ਚੱਲਣ ਯੋਗ ਪੰਨਿਆਂ ਵਜੋਂ ਨਾ ਪਰੋਸੀਆਂ ਜਾਣ।
• Should: ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਦਿਖਾਈਆਂ ਗ਼ਲਤੀਆਂ ਸਾਦੀਆਂ ਹੋਣ ("Something went wrong"); ਵੇਰਵੇ ਵਾਲੀਆਂ ਗ਼ਲਤੀਆਂ ਸਿਰਫ਼ ਸਰਵਰ ਲੌਗ ਵਿੱਚ ਜਾਣ।
• Should: Stripe ਵਰਗੀਆਂ ਸੇਵਾਵਾਂ ਦੇ ਵੈੱਬਹੁੱਕ ਕੁਝ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਦਾਤਾ ਦੇ ਸਿਗਨੇਚਰ ਦੀ ਤਸਦੀਕ ਕਰਨ। ਵੇਖੋ ਵੈੱਬਹੁੱਕ ਕੀ ਹੁੰਦਾ ਹੈ।

ਹਰ ਫਾਰਮ ਅਤੇ API ਐਂਡਪੌਇੰਟ ਵਿੱਚ ਸਰਵਰ-ਪਾਸੇ ਜਾਂਚ ਜੋੜੋ: ਲੋੜੀਂਦੇ ਖੇਤਰ, ਲੰਬਾਈ, ਫਾਰਮੈਟ ਅਤੇ ਇਜਾਜ਼ਤ ਵਾਲੀਆਂ ਕੀਮਤਾਂ। ਬਾਕੀ ਸਭ ਸਾਫ਼ ਸੁਨੇਹੇ ਨਾਲ ਰੱਦ ਕਰੋ। ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਅੰਦਰੂਨੀ ਗ਼ਲਤੀ ਦੇ ਵੇਰਵੇ ਨਾ ਦਿਖਾਓ।

6. ਰੇਟ ਲਿਮਿਟ ਅਤੇ ਦੁਰਵਰਤੋਂ

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

• Must: ਲੌਗ-ਇਨ, ਸਾਈਨਅੱਪ ਅਤੇ ਪਾਸਵਰਡ ਰੀਸੈੱਟ IP ਐਡਰੈੱਸ ਅਤੇ ਅਕਾਊਂਟ ਪ੍ਰਤੀ ਰੇਟ-ਲਿਮਿਟ ਹੋਣ।
• Must: ਹਰ ਉਹ ਕਾਰਵਾਈ ਜੋ ਹਰ ਕਾਲ 'ਤੇ ਪੈਸੇ ਲਗਾਉਂਦੀ ਹੈ (AI ਮਾਡਲ ਬੇਨਤੀਆਂ, SMS, ਈਮੇਲ) ਵਰਤੋਂਕਾਰ ਪ੍ਰਤੀ ਸੀਮਾ ਅਤੇ ਲੌਗ-ਇਨ ਮੰਗੇ।
• Should: ਜਨਤਕ ਫਾਰਮਾਂ (ਸੰਪਰਕ, ਵੇਟਲਿਸਟ) 'ਤੇ ਸਪੈਮ ਸੁਰੱਖਿਆ ਹੋਵੇ: ਰੇਟ ਲਿਮਿਟ, ਲੁਕਵਾਂ ਹਨੀਪਾਟ ਖੇਤਰ, ਜਾਂ CAPTCHA।
• Should: ਆਪਣੇ ਅਦਾਇਗੀ ਪ੍ਰਦਾਤਾਵਾਂ 'ਤੇ ਖ਼ਰਚ ਦੀਆਂ ਹੱਦਾਂ ਜਾਂ ਚੇਤਾਵਨੀਆਂ ਲਗਾਓ, ਤਾਂ ਜੋ ਕੋਈ ਬੱਗ ਜਾਂ ਹਮਲਾਵਰ ਅਨਲਿਮਟਿਡ ਬਿੱਲ ਨਾ ਬਣਾ ਸਕੇ।

7. ਡਿਪੈਂਡੈਂਸੀਆਂ

ਐਪਾਂ ਓਪਨ-ਸੋਰਸ ਪੈਕੇਜਾਂ ਤੋਂ ਬਣਦੀਆਂ ਹਨ, ਅਤੇ ਪੈਕੇਜਾਂ ਵਿੱਚ ਕਈ ਵਾਰ ਜਾਣੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।

• Should: AI ਨੂੰ ਜਾਣੀਆਂ ਕਮਜ਼ੋਰੀਆਂ ਜਾਂਚਣ ਲਈ ਕਹੋ (JavaScript ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ npm audit ਜਾਂ ਤੁਹਾਡੇ ਪੈਕੇਜ ਮੈਨੇਜਰ ਦਾ ਬਰਾਬਰ ਟੂਲ), ਅਤੇ ਪ੍ਰਭਾਵਿਤ ਪੈਕੇਜ ਅੱਪਡੇਟ ਕਰੋ।
• Should: ਉਹ ਪੈਕੇਜ ਹਟਾਓ ਜੋ ਐਪ ਹੁਣ ਨਹੀਂ ਵਰਤਦੀ।
• Should: ਬਹੁਤ ਘੱਟ ਵਰਤੋਂਕਾਰਾਂ ਵਾਲੇ ਪੈਕੇਜਾਂ ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ, ਅਤੇ ਉਨ੍ਹਾਂ ਨਾਵਾਂ ਤੋਂ ਜੋ ਮਸ਼ਹੂਰ ਪੈਕੇਜਾਂ ਦੀਆਂ ਟਾਈਪੋ ਵਰਗੇ ਲੱਗਣ।
• Later: ਹਰ ਇੱਕ-ਦੋ ਮਹੀਨੇ ਬਾਅਦ ਦੁਬਾਰਾ ਜਾਂਚੋ, ਜਾਂ ਜੇ ਤੁਹਾਡਾ ਕੋਡ GitHub 'ਤੇ ਹੈ ਤਾਂ ਆਪਣੇ ਆਪ ਚੇਤਾਵਨੀਆਂ ਚਾਲੂ ਕਰੋ।

8. ਬੈਕਅੱਪ ਅਤੇ ਰਿਕਵਰੀ

ਸੁਰੱਖਿਆ ਵਿੱਚ ਗ਼ਲਤੀਆਂ ਤੋਂ ਉਭਰਨ ਦੀ ਯੋਗਤਾ ਵੀ ਸ਼ਾਮਲ ਹੈ, ਭਾਵੇਂ ਗ਼ਲਤੀ ਤੁਹਾਡੀ ਹੋਵੇ, AI ਦੀ ਜਾਂ ਕਿਸੇ ਹਮਲਾਵਰ ਦੀ।

• Must: ਜਾਣੋ ਕਿ ਤੁਹਾਡਾ ਡੇਟਾ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਕੀ ਉਸਦਾ ਬੈਕਅੱਪ ਹੁੰਦਾ ਹੈ। ਮੰਨ ਕੇ ਨਾ ਚੱਲੋ; ਆਪਣੇ ਹੋਸਟ ਦੇ ਦਸਤਾਵੇਜ਼ ਵੇਖੋ।
• Should: ਮਹੱਤਵਪੂਰਨ ਡੇਟਾ ਦਾ ਆਪਣਾ ਸਮੇਂ-ਸਮੇਂ ਦਾ ਐਕਸਪੋਰਟ ਰੱਖੋ (ਜਿਵੇਂ CSV ਐਕਸਪੋਰਟ ਫੀਚਰ ਜਾਂ ਡੇਟਾਬੇਸ ਡੰਪ), ਕਿਸੇ ਵੱਖਰੀ ਥਾਂ 'ਤੇ ਰੱਖਿਆ ਹੋਵੇ।
• Should: ਆਪਣਾ ਕੋਡ ਵਰਜ਼ਨ ਕੰਟਰੋਲ ਵਿੱਚ ਰੱਖੋ, ਤਾਂ ਜੋ ਕੋਈ ਵੀ ਵਰਜ਼ਨ ਵਾਪਸ ਲਿਆਂਦਾ ਜਾ ਸਕੇ।
• Should: ਵਿਨਾਸ਼ਕਾਰੀ ਕਾਰਵਾਈਆਂ (ਅਕਾਊਂਟ ਮਿਟਾਉਣਾ, ਪ੍ਰੋਜੈਕਟ ਮਿਟਾਉਣਾ) ਪੁਸ਼ਟੀ ਮੰਗਣ, ਅਤੇ ਕੁਝ ਸਮੇਂ ਲਈ ਵਾਪਸ ਹੋਣ ਯੋਗ "ਸਾਫ਼ਟ ਡਿਲੀਟ" 'ਤੇ ਵਿਚਾਰ ਕਰੋ।
• Later: ਇੱਕ ਵਾਰ ਅਸਲ ਵਿੱਚ ਰੀਸਟੋਰ ਟੈਸਟ ਕਰੋ। ਜਿਹੜਾ ਬੈਕਅੱਪ ਕਦੇ ਰੀਸਟੋਰ ਨਹੀਂ ਕੀਤਾ, ਉਹ ਯੋਜਨਾ ਨਹੀਂ, ਸਿਰਫ਼ ਉਮੀਦ ਹੈ।

9. ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ

• Must: ਲਾਈਵ ਸਾਈਟ ਹਰ ਥਾਂ HTTPS ਵਰਤੇ।
• Must: ਵਿਕਾਸ ਦੇ ਨਮੂਨਾ ਡੇਟਾ, ਟੈਸਟ ਅਕਾਊਂਟ ਅਤੇ ਡੀਬੱਗ ਪੰਨੇ ਹਟਾਏ ਜਾਣ।
• Should: ਇੱਕ ਪਰਾਈਵੇਸੀ ਨੀਤੀ ਦੱਸੇ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਡੇਟਾ ਅਤੇ ਕਿਉਂ ਇਕੱਠਾ ਕਰਦੇ ਹੋ; ਜੇ ਤੁਸੀਂ ਨਿੱਜੀ ਡੇਟਾ ਇਕੱਠਾ ਕਰਦੇ ਹੋ ਤਾਂ ਬਹੁਤ ਸਾਰੀਆਂ ਥਾਵਾਂ 'ਤੇ ਇਹ ਲਾਜ਼ਮੀ ਹੈ। ਉਹ ਪ੍ਰਮਾਣੀਕਰਨ (SOC 2, HIPAA) ਦਾਅਵਾ ਨਾ ਕਰੋ ਜੋ ਤੁਹਾਡੇ ਕੋਲ ਨਹੀਂ ਹਨ।
• Should: ਸੁਰੱਖਿਆ ਮੁੱਦਿਆਂ ਲਈ ਸੰਪਰਕ ਦਾ ਰਸਤਾ ਹੋਵੇ, ਅਤੇ ਤੁਸੀਂ ਹਰ ਕੀ ਨੂੰ ਜਲਦੀ ਬਦਲਣਾ ਜਾਣਦੇ ਹੋ।

ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਆ ਤੋਂ ਅੱਗੇ ਵਿਆਪਕ ਜਾਂਚ ਲਈ, ਵੇਖੋ AI ਪ੍ਰੋਟੋਟਾਈਪ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਤੱਕ ਕਿਵੇਂ ਲੈ ਜਾਈਏ।

ਪੇਸ਼ੇਵਰ ਸਮੀਖਿਆ ਕਦੋਂ ਲੈਣੀ ਹੈ

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

Mythex 'ਤੇ ਬਣਾਉਣ ਸਮੇਂ ਸੁਰੱਖਿਆ

Mythex ਵਿੱਚ ਸੁਰੱਖਿਆ-ਸਕੈਨ ਪੈਨਲ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਉੱਪਰ ਦੀ ਚੈੱਕਲਿਸਟ ਹੀ ਅਨੁਸਰਨ ਕਰਨ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਕੁਝ ਗੱਲਾਂ ਜੋ ਮਦਦ ਕਰਦੀਆਂ ਹਨ:

• ਪ੍ਰੋਜੈਕਟ ਸੀਕ੍ਰੇਟਸ। ਕੀਜ਼ ਪ੍ਰੋਜੈਕਟ ਸੈਟਿੰਗਾਂ → Secrets ਹੇਠ ਰੱਖੋ, ਜਾਂ ਏਜੰਟ ਵੱਲੋਂ ਚੈਟ ਵਿੱਚ ਦਿਖਾਏ ਸੀਕ੍ਰੇਟਸ ਕਾਰਡ ਰਾਹੀਂ, ਤਾਂ ਜੋ ਉਹ ਤੁਹਾਡੇ ਕੋਡ ਅਤੇ ਸੁਨੇਹਿਆਂ ਤੋਂ ਬਾਹਰ ਰਹਿਣ। ਲਾਈਵ ਐਪ ਲਈ ਕੋਈ ਸੀਕ੍ਰੇਟ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ।
• Plan ਅਤੇ Ask ਮੋਡ। ਏਜੰਟ ਨੂੰ ਬਿਨਾਂ ਸੋਧੇ ਇਜਾਜ਼ਤਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰਨ ਲਈ ਕਹੋ: "Ask ਮੋਡ ਵਿੱਚ, ਹਰ API ਰੂਟ ਅਤੇ ਉਸਦੀ ਇਜਾਜ਼ਤ ਜਾਂਚ ਦੀ ਸੂਚੀ ਦਿਓ।"
• /test ਏਜੰਟ ਨੂੰ ਤੁਹਾਡੇ ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਇੱਕ ਵਰਤੋਂਕਾਰ ਵਾਂਗ ਕਲਿੱਕ ਕਰਵਾਉਂਦਾ ਹੈ, ਜੋ ਸੈਕਸ਼ਨ 2 ਦੇ ਦੋ-ਅਕਾਊਂਟ ਟੈਸਟ ਲਈ ਲਾਭਦਾਇਕ ਹੈ।
• ਚੈੱਕਪੌਇੰਟ ਤੁਹਾਨੂੰ ਉਹ ਬਦਲਾਅ ਵਾਪਸ ਲੈਣ ਦਿੰਦੇ ਹਨ ਜੋ ਕੁਝ ਤੋੜ ਦੇਵੇ।

ਵੇਖੋ ਤੁਹਾਡੀਆਂ ਬਣਾਈਆਂ ਐਪਾਂ ਲਈ ਸੁਰੱਖਿਆ ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਐਨਵਾਇਰਮੈਂਟ ਵੇਰੀਏਬਲ ਅਤੇ ਸੀਕ੍ਰੇਟਸ। ਜੇ ਤੁਸੀਂ ਅਗਲੇ ਕਦਮ ਵਜੋਂ ਵਰਤੋਂਕਾਰ ਅਕਾਊਂਟ ਜੋੜ ਰਹੇ ਹੋ, ਤਾਂ ਆਪਣੀ ਐਪ ਵਿੱਚ ਲੌਗ-ਇਨ ਕਿਵੇਂ ਜੋੜੀਏ ਪੜ੍ਹੋ।

ਸਵਾਲ