ਕੋਡ ਦੀ ਇੱਕ ਲਾਈਨ ਤੁਹਾਡੇ ਪੂਰੇ ਐਕਸੈਸ ਕੰਟਰੋਲ ਮਾਡਲ ਨੂੰ ਖਤਮ ਕਰ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਰਿਕਵੈਸਟ ਬਾਡੀ ਨੂੰ ਸਿੱਧਾ ਡਾਟਾਬੇਸ ਅਪਡੇਟ ਵਿੱਚ ਪਾ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਕਲਾਇੰਟ ਨੂੰ ਤੁਹਾਡੇ ਸਕੀਮਾ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਲਈ ਇੱਕ ਕਲਮ ਫੜਾ ਦਿੱਤੀ ਹੈ। ਇਸ ਨੂੰ ਮਾਸ ਅਸਾਈਨਮੈਂਟ (mass assignment) ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਕੋਈ ਅਜੀਬ ਬੱਗ ਜਾਂ ਕੋਈ ਦੁਰਲੱਭ ਮਾਮਲਾ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਡਿਜ਼ਾਈਨ ਦੀ ਅਸਫਲਤਾ ਹੈ ਜੋ ਉਦੋਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਜਦੋਂ ਕੋਈ API ਪੇਲੋਡ ਨੂੰ ਆਪਣੀ ਅਪਡੇਟ ਪਾਲਿਸੀ ਵਜੋਂ ਮੰਨ ਲੈਂਦੀ ਹੈ।

await db.users.update(req.params.id, { ...req.body });

ਇਹ ਦੇਖਣ ਵਿੱਚ ਸਾਫ਼ ਲੱਗਦਾ ਹੈ। ਇਸ ਨਾਲ ਟਾਈਪਿੰਗ ਬਚਦੀ ਹੈ। ਪਰ ਕਲਾਇੰਟ ਕੋਲ 'ਕੀਜ਼' (keys) ਦਾ ਕੰਟਰੋਲ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਅਟੈਕਰ ਇੱਕ ਆਮ ਪ੍ਰੋਫਾਈਲ ਅਪਡੇਟ ਵਿੱਚ "role": "admin", "accountId": "someone_else", ਜਾਂ "credit": 99999" ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਜੋੜ ਸਕਦਾ ਹੈ। ਤੁਹਾਡੀ ਵੈਲੀਡੇਸ਼ਨ ਲੇਅਰ ਸ਼ਾਇਦ ਇਹ ਚੈੱਕ ਕਰੇ ਕਿ ਉਹ ਵੈਲਯੂਜ਼ ਸਟ੍ਰਿੰਗ ਹਨ ਜਾਂ ਨੰਬਰ ਅਤੇ ਕਹੇ ਕਿ ਉਹ ਠੀਕ ਲੱਗਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਵੈਲਿਡਿਟੀ (validity) ਦਾ ਮਤਲਬ ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ (authorization) ਨਹੀਂ ਹੈ। ਇੱਕ ਯੂਜ਼ਰ ਕੋਲ ਜਾਇਜ਼ ਤੌਰ 'ਤੇ ਟਾਰਗੇਟ ਰਿਕਾਰਡ ਹੋ ਸਕਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਉਸ ਕੋਲ ਇਸਦੇ ਅੰਦਰ ਹਰ ਫੀਲਡ ਨੂੰ ਐਡਿਟ ਕਰਨ ਦਾ ਅਧਿਕਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਮਾਸ ਅਸਾਈਨਮੈਂਟ ਅਸਲ ਵਿੱਚ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ

ਖ਼ਤਰਾ ਸਹੂਲਤ ਵਿੱਚ ਲੁਕਿਆ ਹੁੰਦਾ ਹੈ। ਫਰੇਮਵਰਕਸ ਅਤੇ ORMs JSON ਕੀਜ਼ ਨੂੰ ਸਿੱਧਾ ਡਾਟਾਬੇਸ ਕਾਲਮਾਂ ਨਾਲ ਮੈਪ ਕਰਨਾ ਬਹੁਤ ਆਸਾਨ ਬਣਾ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਅਜਿਹਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਡਾਟਾਬੇਸ ਨੂੰ ਇਹ ਭਰੋਸਾ ਦਿਵਾ ਰਹੇ ਹੁੰਦੇ ਹੋ ਕਿ ਕੀ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇਹ ਕਿ ਕਿਵੇਂ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ।

ਆਪਣੀ ਪ੍ਰੋਫਾਈਲ ਅਪਡੇਟ ਕਰਨ ਵਾਲਾ ਯੂਜ਼ਰ displayName ਅਤੇ bio ਲਈ ਵੈਲਿਡ ਡੇਟਾ ਭੇਜ ਸਕਦਾ ਹੈ, ਪਰ ਉਹਨਾਂ ਦੇ ਨਾਲ role ਜਾਂ balance ਵੀ ਲੁਕਾ ਕੇ ਭੇਜ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਕੰਟਰੋਲਰ ਸਿਰਫ਼ ਉਸ ਆਬਜੈਕਟ ਨੂੰ ਅੱਗੇ ਭੇਜ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਡਾਟਾਬੇਸ ਸਭ ਕੁਝ ਲਿਖ ਦਿੰਦਾ ਹੈ। ਵੈਲੀਡੇਸ਼ਨ ਗਲਤ ਫਾਰਮੈਟ ਵਾਲੀਆਂ ਵੈਲਯੂਜ਼ ਨੂੰ ਫੜ ਲੈਂਦੀ ਹੈ। ਇਹ ਸ਼ਾਇਦ ਹੀ ਕਿਸੇ ਮਾਲੀਸ਼ੀਅਸ (malicious) ਕੀਜ਼ ਨੂੰ ਫੜ ਸਕੇ। ਉਹ ਬਿਜ਼ਨਸ ਰੂਲ ਜੋ ਕਹਿੰਦਾ ਹੈ ਕਿ "ਇਸ ਯੂਜ਼ਰ ਨੂੰ ਆਪਣੀ ਪ੍ਰੋਫਾਈਲ ਅਪਡੇਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ", ਉਹ ਰੋਅ (row) ਦੇ ਹਰ ਕਾਲਮ 'ਤੇ ਇੱਕ ਅੰਨ੍ਹੀ ਇਜਾਜ਼ਤ ਬਣ ਜਾਂਦਾ ਹੈ।

ਇਸਦਾ ਹੱਲ ਹੋਰ ਵੈਲੀਡੇਸ਼ਨ ਨਹੀਂ ਹੈ। ਇਹ ਵਧੇਰੇ ਸਖ਼ਤ ਆਰਕੀਟੈਕਚਰ ਹੈ।

ਤਿੰਨ ਦਰਵਾਜ਼ੇ (The Three Gates)

ਇੱਕ ਸੁਰੱਖਿਅਤ ਮਿਊਟੇਸ਼ਨ ਸਟੋਰੇਜ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਚੈੱਕਾਂ ਵਿੱਚੋਂ ਲੰਘਦੀ ਹੈ।

ਸਵੀਕਾਰ ਕੀਤੇ ਗਏ ਫੀਲਡਸ (Allowlist)

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀਆਂ ਕੀਜ਼ (keys) ਨੂੰ ਦੇਖੋਗੇ। ਜੇਕਰ ਕੋਈ ਫੀਲਡ ਐਲੋਲਿਸਟ (allowlist) ਵਿੱਚ ਨਹੀਂ ਹੈ, ਤਾਂ ਰਿਕਵੈਸਟ ਨੂੰ ਰੱਦ ਕਰ ਦਿਓ ਜਾਂ ਉਸ ਕੀ ਨੂੰ ਹਟਾ ਦਿਓ। ਇਹ ਡਿਫੌਲਟ ਸਥਿਤੀ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ: ਨਵੇਂ ਡਾਟਾਬੇਸ ਕਾਲਮ ਉਦੋਂ ਤੱਕ ਲਿਖਣਯੋਗ (non-writable) ਨਹੀਂ ਹੁੰਦੇ ਜਦੋਂ ਤੱਕ ਕੋਈ ਡਿਵੈਲਪਰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਐਕਸਪੋਜ਼ ਨਹੀਂ ਕਰਦਾ। ਸਮੇਂ ਦੇ ਨਾਲ ਸਕੀਮਾ ਵਧਦੇ ਹਨ। ਕੋਈ ਸਾਥੀ stripeCustomerId, departmentBudget, ਜਾਂ isVerified ਫਲੈਗ ਜੋੜਦਾ ਹੈ। ਐਲੋਲਿਸਟ ਦੇ ਨਾਲ, ਉਹ ਨਵੇਂ ਕਾਲਮ ਆਪਣੇ ਆਪ ਕਲਾਇੰਟ ਰਾਈਟਸ ਤੋਂ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦੇ ਹਨ। ਇਸ ਤੋਂ ਬਿਨਾਂ, ਹਰ ਨਵਾਂ ਕਾਲਮ ਅਣਜਾਣੇ ਵਿੱਚ ਇੱਕ API ਸਰਫੇਸ ਬਣ ਜਾਂਦਾ ਹੈ।

ਵੈਲਿਡ ਵੈਲਯੂਜ਼ (Valid Values)

ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਫੀਲਡਸ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, ਤਾਂ ਚੈੱਕ ਕਰੋ ਕਿ ਕੀ ਉਹ ਵੈਲਯੂਜ਼ ਸਹੀ ਹਨ। ਕੀ ਟਾਈਮਜ਼ੋਨ ਸਟ੍ਰਿੰਗ ਅਸਲ ਵਿੱਚ ਇੱਕ ਮਾਨਤਾ ਪ੍ਰਾਪਤ ਟਾਈਮਜ਼ੋਨ ਹੈ? ਕੀ ਈਮੇਲ ਦਾ ਫਾਰਮੈਟ ਈਮੇਲ ਵਰਗਾ ਹੈ? ਕੀ ਨੰਬਰ ਇੱਕ ਤਰਕਸੰਗਤ ਰੇਂਜ ਦੇ ਅੰਦਰ ਹੈ? ਇਹ ਸਿਰਫ਼ ਸਫਾਈ (hygiene) ਹੈ। ਇਹ ਤੁਹਾਡੇ ਸਿਸਟਮ ਵਿੱਚ ਗਲਤ ਡੇਟਾ ਨੂੰ ਜਾਣ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਪਰ ਇਹ ਦੁਰਵਰਤੋਂ ਨੂੰ ਨਹੀਂ ਰੋਕਦਾ। ਇੱਕ ਬਿਲਕੁਲ ਵੈਲਿਡ "admin" ਸਟ੍ਰਿੰਗ ਵੀ role ਫੀਲਡ ਵਿੱਚ ਖ਼ਤਰਨਾਕ ਹੋ ਸਕਦੀ ਹੈ ਜੇਕਰ ਗਲਤ ਵਿਅਕਤੀ ਇਸਨੂੰ ਭੇਜਦਾ ਹੈ।

ਅਥੋਰਾਈਜ਼ਡ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨਜ਼ (Authorized Transitions)

ਇਹ ਉਹ ਦਰਵਾਜ਼ਾ ਹੈ ਜਿਸ ਨੂੰ ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਥੇ ਹੀ ਅਸਲ ਸੁਰੱਖਿਆ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਬਾਰੀਕ ਸਵਾਲ ਪੁੱਛੋ: ਕੀ ਇਸ ਖਾਸ ਐਕਟਰ ਕੋਲ ਇਸ ਖਾਸ ਰਿਕਾਰਡ 'ਤੇ ਇਸ ਖਾਸ ਫੀਲਡ ਨੂੰ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ? ਇਹ ਨਹੀਂ ਕਿ "ਕੀ ਯੂਜ਼ਰ ਐਡਮਿਨ ਹੈ?" ਜਾਂ "ਕੀ ਯੂਜ਼ਰ ਕੋਲ write:users ਸਕੋਪ ਹੈ?" ਸਗੋਂ, "ਕੀ ਇਸ ਯੂਜ਼ਰ ਨੂੰ ਆਪਣਾ displayName ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, ਪਰ ਕਦੇ ਵੀ ਆਪਣਾ accountId ਨਹੀਂ?" ਫੀਲਡ-ਦਰ-ਫੀਲਡ ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਇੱਕ ਵਿਸ਼ਾਲ ਪਰਮਿਸ਼ਨ ਜਿਵੇਂ ਕਿ "Editor" ਜਾਂ "User" ਨੂੰ ਰੋਅ ਦੀ ਹਰ ਪ੍ਰਾਪਰਟੀ ਦੀ ਮਾਸਟਰ ਕੀ ਬਣਨ ਤੋਂ ਰੋਕਦੀ ਹੈ।

ਪੈਚ ਫੰਕਸ਼ਨ (Patch Function) ਬਣਾਉਣਾ

ਤਿੰਨਾਂ ਦਰਵਾਜ਼ਿਆਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਜੋੜੋ। ਜਦੋਂ ਕੋਈ ਪੈਚ ਰਿਕਵੈਸਟ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਕ੍ਰਮਵਾਰ ਪੜਾਵਾਂ ਵਿੱਚੋਂ ਲੰਘਾਓ।

ਪਹਿਲਾਂ, ਆਪਣੇ ਐਲੋਲਿਸਟ ਦੇ ਵਿਰੁੱਧ ਇਨਪੁਟ ਨੂੰ ਫਿਲਟਰ ਕਰੋ। ਜੇਕਰ role ਇਸ ਐਂਡਪੁਆਇੰਟ ਲਈ ਇੱਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਫੀਲਡ ਨਹੀਂ ਹੈ, ਤਾਂ ਉੱਥੇ ਹੀ ਰੁਕ ਜਾਓ। ਉਸ ਵੈਲਯੂ ਨੂੰ ਵੈਲੀਡੇਟ ਜਾਂ ਅਥੋਰਾਈਜ਼ ਕਰਨ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਕਦੇ ਮਿਲਣੀ ਹੀ ਨਹੀਂ ਚਾਹੀਦੀ ਸੀ।

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

ਤੀਜਾ, ਐਕਸ਼ਨ ਨੂੰ ਅਥੋਰਾਈਜ਼ ਕਰੋ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਕਟਰ ਕੋਲ ਟਾਰਗੇਟ ਰਿਕਾਰਡ ਦੀ ਮਲਕੀਅਤ ਹੈ, ਜਾਂ ਇਸ ਫੀਲਡ ਲਈ ਲੋੜੀਂਦੀ ਸਹੀ ਪਰਮਿਸ਼ਨ ਹੈ। ਨਿੱਜੀ ਡੇਟਾ ਲਈ ਮਲਕੀਅਤ (ownership) ਇੱਕ ਚੰਗਾ ਡਿਫੌਲਟ ਹੈ, ਪਰ ਕੁਝ ਫੀਲਡਸ ਨੂੰ ਅਜੇ ਵੀ ਵਾਧੂ ਦ

ਜੇਕਰ ਇਨਪੁਟ ਕਿਸੇ ਵੀ ਗੇਟ (gate) 'ਤੇ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਪੂਰੀ ਮਿਊਟੇਸ਼ਨ (mutation) ਨੂੰ ਰੱਦ ਕਰ ਦਿਓ। ਸੁਰੱਖਿਅਤ ਫੀਲਡਾਂ ਨੂੰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਲਾਗੂ ਨਾ ਕਰੋ ਅਤੇ ਖ਼ਰਾਬ ਵਾਲਿਆਂ ਨੂੰ ਚੁੱਪਚਾਪ ਡ੍ਰੌਪ ਨਾ ਕਰੋ। ਇੱਕ ਮਿਸ਼ਰਤ ਜਵਾਬ ਕਲਾਇੰਟਸ ਨੂੰ ਹਰ ਉਹ ਕੀ (key) ਵਰਤਣ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ ਜੋ ਉਹ ਸੋਚ ਸਕਦੇ ਹਨ ਅਤੇ ਦੇਖਦੇ ਹਨ ਕਿ ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਫੇਲ ਹੋਣ ਦਾ ਸੰਕੇਤ ਦਿਓ।

ਉਹ ਐਜ ਕੇਸ (Edge Cases) ਜੋ ਅਸਲ ਵਿੱਚ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ

ਮਾਸ ਅਸਾਈਨਮੈਂਟ (Mass assignment) ਦੀ ਰੱਖਿਆ ਉਹਨਾਂ ਵੇਰਵਿਆਂ 'ਤੇ ਟਿਕੀ ਹੁੰਦੀ ਹੈ ਜੋ ਯੂਨਿਟ ਟੈਸਟਾਂ (unit tests) ਤੋਂ ਅਕਸਰ ਰਹਿ ਜਾਂਦੇ ਹਨ।

ਡੁਪਲੀਕੇਟ JSON keys। ਹਮਲਾਵਰ {"role": "user", "role": "admin"} ਵਰਗੇ ਪੇਲੋਡ (payloads) ਭੇਜ ਸਕਦੇ ਹਨ। ਤੁਹਾਡੇ HTTP ਪਾਰਸਰ (parser) ਅਤੇ ਫਰੇਮਵਰਕ (framework) ਦੇ ਅਧਾਰ 'ਤੇ, ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਦੁਆਰਾ ਆਬਜੈਕਟ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਦੂਜੀ ਕੀ (key) ਪਹਿਲੀ ਨੂੰ ਓਵਰਰਾਈਟ (overwrite) ਕਰ ਸਕਦੀ ਹੈ। ਇਸ ਵਿਵਹਾਰ ਦਾ ਪਾਰਸਰ ਪੱਧਰ 'ਤੇ ਟੈਸਟ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਡਾ ਫਰੇਮਵਰਕ ਚੁੱਪਚਾਪ ਆਖਰੀ ਕੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਅਲਾਓਲਿਸਟ (allowlist) "user" ਨੂੰ ਦੇਖ ਰਹੀ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਡਾਟਾਬੇਸ ਨੂੰ "admin" ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ।

ਨੇਸਟਡ ਆਬਜੈਕਟਸ (Nested objects), nulls, ਅਤੇ ਐਰੇਜ਼ (arrays)। ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਪੇਲੋਡ ਫਲੈਟ (flat) ਹੈ। ਇੱਕ ਕਲਾਇੰਟ ਇੱਕ ਸੀਮਤ ਫੀਲਡ ਨੂੰ { "profile": { "role": "admin" } } ਵਰਗੇ ਨੇਸਟਡ ਆਬਜੈਕਟ ਦੇ ਅੰਦਰ ਰੱਖ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਸਕੀਮਾ (schema) ਰਿਕਰਸ (recurse) ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਅਲਾਓਲਿਸਟ ਨੂੰ ਵੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ null ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦੇ ਹੋ। ਕੀ ਇਸਦਾ ਮਤਲਬ "ਇਸ ਫੀਲਡ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ" ਹੈ ਜਾਂ "ਇਸ ਫੀਲਡ ਨੂੰ ਡਿਲੀਟ ਕਰੋ"? ਅਤੇ ਜੇਕਰ ਇੱਕ ਐਰੇ (array) ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕੀ ਤੁਹਾਡਾ ਵੈਲੀਡੇਟਰ (validator) ਅਣਉਮੀਦ ਢਾਂਚੇ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਇਹ ਇੱਕ ਸਿੰਗਲ ਆਬਜੈਕਟ ਨੂੰ ਐਰੇ ਵਿੱਚ ਬਦਲ ਕੇ ਅੱਗੇ ਜਾਣ ਦਿੰਦਾ ਹੈ?

ਯੂਨੀਕੋਡ ਨਾਰਮਲਾਈਜ਼ੇਸ਼ਨ (Unicode normalization)। ਦੋ ਸਟ੍ਰਿੰਗਾਂ (strings) ਇੱਕ ਇਨਸਾਨ ਨੂੰ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਖ ਸਕਦੀਆਂ ਹਨ ਪਰ ਉਹ ਬਾਈਟਸ (bytes) ਦੇ ਵੱਖਰੇ ਕ੍ਰਮ ਹੋ ਸਕਦੇ ਹਨ। ਇੱਕ ਉਪਭੋਗਤਾ ਇੱਕ ਪ੍ਰੀਕੰਪੋਜ਼ਡ (precomposed) é ਜਾਂ ਇੱਕ ਡੀਕੰਪੋਜ਼ਡ (decomposed) e ਪਲੱਸ ਕੰਬਾਈਨਿੰਗ ਐਕਸੈਂਟ (combining accent) ਭੇਜ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਚੈੱਕ (authorization check) ਇੱਕ ਵਾਰ ਨਾਰਮਲਾਈਜ਼ ਕਰਦਾ ਹੈ ਪਰ ਤੁਹਾਡਾ ਸਟੋਰੇਜ ਲੇਅਰ (storage layer) ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਨਾਰਮਲਾਈਜ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਅਸੰਗਤ ਡਾਟਾ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ, ਇੱਕ ਬਾਈਪਾਸ (bypass) ਹੋ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਯੂਜ਼ਰਨੇਮ ਦੀ ਟੱਕਰ ਤੁਹਾਡੇ ਲੌਜਿਕ ਤੋਂ ਬਚ ਕੇ ਨਿਕਲ ਜਾਂਦੀ ਹੈ। ਜਲਦੀ ਨਾਰਮਲਾਈਜ਼ ਕਰੋ ਅਤੇ ਲਗਾਤਾਰ ਨਾਰਮਲਾਈਜ਼ ਕਰੋ।

ਰੇਸ ਕੰਡੀਸ਼ਨਜ਼ (Race conditions)। ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਫੈਸਲੇ ਫ੍ਰੀਜ਼ ਫਰੇਮ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਇੱਕ ਸਮੇਂ 'ਤੇ ਹੁੰਦੇ ਹਨ। ਦੋ ਰਿਕੁਐਸਟਾਂ ਇੱਕੋ ਰਿਕਾਰਡ ਨੂੰ ਪੜ੍ਹ ਸਕਦੀਆਂ ਹਨ, ਦੋਵੇਂ ਦੇਖ ਸਕਦੀਆਂ ਹਨ ਕਿ ਐਕਟਰ (actor) ਨੂੰ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਅੱਪਡੇਟ ਜਾਰੀ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਦਰਮਿਆਨ, ਸਟੇਟ (state) ਜਾਂ ਐਕਟਰ ਦੀਆਂ ਇਜਾਜ਼ਤਾਂ ਬਦਲ ਸਕਦੀਆਂ ਹਨ। ਹਮੇਸ਼ਾ ਵਰਜ਼ਨ ਨੰਬਰ ਜਾਂ ਸਟੇਟ ਮਸ਼ੀਨ (state machine) ਮੁੱਲ 'ਤੇ ਸ਼ਰਤ ਦੇ ਨਾਲ ਡਾਟਾਬੇਸ ਅੱਪਡੇਟ ਲਾਗੂ ਕਰੋ। ਕੁਝ ਅਜਿਹਾ ਵਰਤੋ ਜਿਵੇਂ ਕਿ UPDATE users SET ... WHERE id = ? AND version = 5। ਜੇਕਰ ਤੁਹਾਡੇ ਪੜ੍ਹਨ ਤੋਂ ਬਾਅਦ ਰੋਅ (row) ਬਦਲ ਗਈ ਹੈ, ਤਾਂ ਲਿਖਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਫੇਲ ਹੋ ਜਾਵੇਗੀ। ਫੇਲ ਹੋਣ 'ਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਕੇ ਜਾਂ ਰੱਦ ਕਰਕੇ ਇਸਨੂੰ ਸੰਭਾਲੋ। ਇਹ ਪੁਰਾਣੇ ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਚੈੱਕਸ ਨੂੰ ਤੁਹਾਡੇ ਡਾਟਾ ਨੂੰ ਖਰਾਬ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਜੋ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ ਉਸ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ

ਤੁਸੀਂ ਉਸ ਚੀਜ਼ ਨੂੰ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜਿਸਨੂੰ ਤੁਸੀਂ ਦੇਖ ਨਹੀਂ ਸਕਦੇ। ਆਪਣੀ ਆਡਿਟ ਲੌਗਿੰਗ (audit logging) ਨੂੰ ਸਿਰਫ਼ ਕਾਰਵਾਈ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਨਹੀਂ, ਸਗੋਂ ਫੈਸਲੇ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਾਓ।

ਐਕਟਰ ਆਈਡੀ (actor ID) ਅਤੇ ਟਾਰਗੇਟ ਆਈਡੀ (target ID) ਨੂੰ ਲੌਗ ਕਰੋ। ਉਹ ਸਹੀ ਫੀਲਡ ਨਾਮ ਲੌਗ ਕਰੋ ਜੋ ਸਵੀਕਾਰ ਕੀਤੇ ਗਏ ਸਨ ਅਤੇ ਉਹ ਜੋ ਰੱਦ ਕੀਤੇ ਗਏ ਸਨ। ਉਹ ਪਾਲਿਸੀ ਵਰਜ਼ਨ (policy version) ਲੌਗ ਕਰੋ ਜਿਸਨੇ ਫੈਸਲਾ ਲਿਆ ਅਤੇ ਅੰਤਿਮ ਨਤੀਜਾ। ਜੇਕਰ ਕੋਈ ਉਪਭੋਗਤਾ ਅਚਾਨਕ ਆਪਣੀ ਪ੍ਰੋਫਾਈਲ ਅੱਪਡੇਟ ਵਿੱਚ role ਨੂੰ ਰੱਦ ਹੋ ਰਿਹਾ ਦੇਖਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਤੁਰੰਤ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ।

ਬੀਅਰਰ ਟੋਕਨ (bearer tokens) ਨੂੰ ਕਦੇ ਵੀ ਲੌਗ ਨਾ ਕਰੋ। ਪੂਰੀ ਰਿਕੁਐਸ ਬਾਡੀ (request body) ਨੂੰ ਆਪਣੇ ਲੌਗਾਂ ਵਿੱਚ ਕਦੇ ਨਾ ਪਾਓ। ਇੱਕ ਆਡਿਟ ਟ੍ਰੇਲ (audit trail) ਨੂੰ ਦੁਰਵਰਤੋਂ ਦੀ ਜਾਂਚ ਕਰਨ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲਜ਼ (credentials) ਅਤੇ ਨਿੱਜੀ ਡਾਟਾ ਦਾ ਭੰਡਾਰ ਬਣਨਾ ਚਾਹੀਦਾ ਹੈ।

ਇਕਲੌਤਾ ਨਿਯਮ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ

ਇੱਕ ਰਿਕੁਐਸ ਬਾਡੀ ਡਾਟਾ ਦਾ ਪ੍ਰਸਤਾਵ ਦਿੰਦੀ ਹੈ। ਇਹ ਕਦੇ ਵੀ ਆਪਣੀ ਖੁਦ ਦੀ ਅਥਾਰਟੀ (authority) ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦੀ। ਕਲਾਇੰਟ ਕੁਝ ਵੀ ਮੰਗ ਸਕਦਾ ਹੈ। ਤੁਹਾਡਾ ਸਰਵਰ ਫੈਸਲਾ ਕਰਦਾ ਹੈ, ਫੀਲਡ-ਦਰ-ਫੀਲਡ ਅਤੇ ਰੋਅ-ਦਰ-ਰੋਅ, ਕਿ ਸਥਾਈ ਸਟੋਰੇਜ (permanent storage) ਵਿੱਚ ਕੀ ਆਉਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ। ਆਪਣੇ ਪੈਚਸ (patches) ਨੂੰ ਉਸੇ ਵੱਖਰੇਵੇਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਬਣਾਓ, ਅਤੇ ਮਾਸ ਅਸਾਈਨਮੈਂਟ ਇੱਕ ਅਜਿਹੀ ਸਮੱਸਿਆ ਬਣ ਜਾਂਦੀ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਆਪਣੇ ਅਥੋਰਾਈਜ਼ੇਸ਼ਨ ਲੇਅਰ (authorization layer) ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਹੀ ਰੋਕ ਦਿੱਤਾ ਸੀ।