AI-ನಿರ್ಮಿತ ಆ್ಯಪ್‌ಗಳಿಗಾಗಿ ಭದ್ರತಾ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ: ಬಿಡುಗಡೆಗೆ ಮೊದಲು ಏನು ಪರಿಶೀಲಿಸಬೇಕು

ನಿಜ ಜನರು ನೀವು AI ಸಹಾಯದಿಂದ ನಿರ್ಮಿಸಿದ ಆ್ಯಪ್ ಬಳಸುವ ಮೊದಲು ಏಳು ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸಿ: ಪ್ರತಿ ಪುಟ ಮತ್ತು API ಬಳಕೆದಾರ ಯಾರು ಮತ್ತು ಅವರು ಏನು ಮಾಡಬಹುದು ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆಯೇ; ರಹಸ್ಯ ಕೀಗಳು ಸರ್ವರ್‌ನಲ್ಲಿ ಮಾತ್ರ ಇವೆಯೇ, ಬ್ರೌಸರ್ ಅಥವಾ ಚಾಟ್‌ನಲ್ಲಿ ಅಲ್ಲ; ಎಲ್ಲ ಇನ್‌ಪುಟ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಮೌಲ್ಯೀಕರಿಸಲ್ಪಡುತ್ತದೆಯೇ; ಪ್ರತಿ ಬಳಕೆದಾರರು ತಮ್ಮ ದಾಖಲೆಗಳನ್ನು ಮಾತ್ರ ತಲುಪಬಹುದೇ; ಲಾಗ್-ಇನ್ ಮತ್ತು ದುಬಾರಿ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳಿಗೆ ರೇಟ್ ಮಿತಿ ಇದೆಯೇ; ಅವಲಂಬನೆಗಳು ನವೀಕೃತವಾಗಿವೆಯೇ; ಏನಾದರೂ ತಪ್ಪಾದರೆ ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಮರುಸ್ಥಾಪಿಸಬಹುದೇ. ಕೆಳಗಿನ ಪಟ್ಟಿ ಇವುಗಳನ್ನು ಕೋಡ್ ಓದದೆಯೇ ನೀವು ನಡೆಸಬಹುದಾದ ನಿರ್ದಿಷ್ಟ ಪರೀಕ್ಷೆಗಳಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.

AI ಆ್ಯಪ್ ಬಿಲ್ಡರ್‌ಗಳು ವೈಶಿಷ್ಟ್ಯಗಳು ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡುವುದರಲ್ಲಿ ಉತ್ತಮ. ಆದರೆ ಅವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಎಚ್ಚರಿಕೆಯಿಂದ ಇರುವುದಿಲ್ಲ, ಏಕೆಂದರೆ "ಎಚ್ಚರಿಕೆ" ಅನ್ನು ಅಪರೂಪವಾಗಿ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ಹೇಳಲಾಗುತ್ತದೆ. ಕೆಳಗಿನ ಬಹುತೇಕ ಸಮಸ್ಯೆಗಳು ಯಾರೂ ಕೇಳದ ವಿಷಯಗಳಿಂದ ಬರುತ್ತವೆ, ಆದ್ದರಿಂದ ಪರಿಹಾರ ಸಾಮಾನ್ಯವಾಗಿ ಕೇಳುವುದು.

ಈ ಪಟ್ಟಿಯನ್ನು ಹೇಗೆ ಬಳಸುವುದು

ಕ್ರಮವಾಗಿ ಕೆಲಸ ಮಾಡಿ, ಮತ್ತು ಪ್ರತಿ ಐಟಂಗೆ ಎರಡು ಕೆಲಸಗಳನ್ನು ಮಾಡಿ: ಅದನ್ನು ನಿಭಾಯಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಲು AI ಅನ್ನು ಕೇಳಿ, ಮತ್ತು ನೀವೇ ಪರೀಕ್ಷಿಸಿ. ಅನುಮತಿ ಪರಿಶೀಲನೆಯನ್ನು AI ಬರೆಯಬಹುದು; ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಪರೀಕ್ಷೆ ಮಾತ್ರ ಹೇಳುತ್ತದೆ. ಐಟಂಗಳನ್ನು ಗುರುತಿಸಲಾಗಿದೆ:

• Must — ಯಾರಾದರೂ ಆ್ಯಪ್ ಬಳಸುವ ಮೊದಲು ಇದನ್ನು ಮಾಡಿ.
• Should — ನಿಮಗೆ ನಿಜ ಬಳಕೆದಾರರು ಅಥವಾ ನಿಜ ಡೇಟಾ ಬರುವ ಮೊದಲು ಇದನ್ನು ಮಾಡಿ.
• Later — ಆ್ಯಪ್ ಬೆಳೆದಂತೆ ಮಾಡುವುದು ಯೋಗ್ಯ.

ನಿಮ್ಮ ಬಳಿ ಒಂದೇ ಗಂಟೆ ಇದ್ದರೆ, ಪ್ರತಿ Must ಅನ್ನು ಮಾಡಿ.

1. ದೃಢೀಕರಣ: ಇವರು ಯಾರು?

ದೃಢೀಕರಣ ಎಂದರೆ ಯಾರೆಂದು ಖಚಿತಪಡಿಸುವುದು, ಸಾಮಾನ್ಯವಾಗಿ ಲಾಗ್-ಇನ್. ಮೂಲಭೂತ ವಿಷಯಗಳಿಗೆ ದೃಢೀಕರಣ ಎಂದರೇನು ಮತ್ತು ಆಯ್ಕೆಗಳಿಗೆ ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಲಾಗ್-ಇನ್ ಹೇಗೆ ಸೇರಿಸುವುದು ನೋಡಿ.

• Must: ಖಾಸಗಿ ಡೇಟಾ ತೋರಿಸುವ ಪ್ರತಿ ಪುಟಕ್ಕೆ ಲಾಗ್-ಇನ್ ಬೇಕು. ಪರೀಕ್ಷೆ: ಲಾಗ್ ಔಟ್ ಮಾಡಿ, ನಂತರ ಖಾಸಗಿ ಪುಟದ URL ಅನ್ನು ನೇರವಾಗಿ ಬ್ರೌಸರ್‌ಗೆ ಅಂಟಿಸಿ.
• Must: ಆ ಪುಟಗಳ ಹಿಂದಿನ ಪ್ರತಿ API ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೂ ಲಾಗ್-ಇನ್ ಬೇಕು — ಕೇವಲ ಪುಟಕ್ಕಲ್ಲ. ಪರೀಕ್ಷೆ: ಲಾಗ್ ಔಟ್ ಮಾಡಿ, ಬ್ರೌಸರ್‌ನ ನೆಟ್‌ವರ್ಕ್ ಟ್ಯಾಬ್ ತೆರೆಯಿರಿ, ನೀವು ಲಾಗ್ ಇನ್ ಆಗಿದ್ದಾಗ ಆ್ಯಪ್ ಮಾಡಿದ ವಿನಂತಿಯನ್ನು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ.
• Must: ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ನಿಧಾನ ಪಾಸ್‌ವರ್ಡ್-ಹ್ಯಾಶಿಂಗ್ ಅಲ್ಗಾರಿದಮ್‌ನೊಂದಿಗೆ ಹ್ಯಾಶ್ ಮಾಡಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಎಂದಿಗೂ ಸರಳ ಪಠ್ಯದಲ್ಲಿ ಅಲ್ಲ. OWASP ನ ಪಾಸ್‌ವರ್ಡ್ ಸಂಗ್ರಹಣಾ ಮಾರ್ಗದರ್ಶನ Argon2id ಅನ್ನು ಮೊದಲು ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ, scrypt, bcrypt ಅಥವಾ PBKDF2 ಪರ್ಯಾಯಗಳಾಗಿ. ಕೇಳಿ: "ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ?"
• Should: ಪಾಸ್‌ವರ್ಡ್ ಮರುಹೊಂದಿಸುವ ಲಿಂಕ್‌ಗಳು ಅವಧಿ ಮುಗಿಯುತ್ತವೆ ಮತ್ತು ಒಮ್ಮೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತವೆ.
• Should: ಸೆಷನ್ ಕುಕೀಗಳು Secure, HttpOnly ಮತ್ತು SameSite ಎಂದು ಗುರುತಿಸಲ್ಪಟ್ಟಿವೆ, ಮತ್ತು ಲಾಗ್ ಔಟ್ ಮಾಡಿದರೆ ಸರ್ವರ್‌ನಲ್ಲಿ ಸೆಷನ್ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.
• Later: ಎರಡು-ಅಂಶ ದೃಢೀಕರಣ ನೀಡಿ, ಅಥವಾ ಅದನ್ನು ಹೊಂದಿರುವ ಪೂರೈಕೆದಾರರ ಮೂಲಕ ಸೈನ್-ಇನ್ ನೀಡಿ.

ಬಳಕೆದಾರರ ಡೇಟಾ ಹಿಂತಿರುಗಿಸುವ ಪ್ರತಿ API ಮಾರ್ಗ ಮತ್ತು ಪುಟವನ್ನು ಪರಿಶೀಲಿಸಿ. ಪ್ರತಿಯೊಂದೂ ಲಾಗ್ ಇನ್ ಆಗದ ಬಳಕೆದಾರರ ವಿನಂತಿಗಳನ್ನು ತಿರಸ್ಕರಿಸಬೇಕು, ಪುಟದ ಕೋಡ್‌ನಲ್ಲಿ ಮಾತ್ರವಲ್ಲ, ಸರ್ವರ್‌ನಲ್ಲಿ. ನೀವು ಪರಿಶೀಲಿಸಿದ ಮಾರ್ಗಗಳ ಪಟ್ಟಿ ಮಾಡಿ.

2. ಅಧಿಕಾರ: ಅವರು ಏನು ಮಾಡಲು ಅನುಮತಿಸಲಾಗಿದೆ?

ಅಧಿಕಾರ ಲಾಗ್-ಇನ್ ನಂತರದ ಹಂತ: ಈ ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರರು ಏನನ್ನು ನೋಡಬಹುದು ಮತ್ತು ಬದಲಿಸಬಹುದು ಎಂದು ನಿರ್ಧರಿಸುವುದು. 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: ಹಣ ಖರ್ಚು ಮಾಡಬಹುದಾದ ಅಥವಾ ಖಾಸಗಿ ಡೇಟಾ ಓದಬಹುದಾದ ಕೀಗಳನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಮಾತ್ರ ಬಳಸಲಾಗುತ್ತದೆ. ಪರೀಕ್ಷೆ: ನಿಮ್ಮ ಲೈವ್ ಸೈಟ್ ತೆರೆಯಿರಿ, ಪುಟದ ಸೋರ್ಸ್ ಮತ್ತು devtools ನಲ್ಲಿರುವ JavaScript ಫೈಲ್‌ಗಳನ್ನು ನೋಡಿ, ನಿಮ್ಮ ಕೀಯ ಆರಂಭವನ್ನು (ಉದಾಹರಣೆಗೆ sk_) ಹುಡುಕಿ. ಅದು ಕಾಣಬಾರದು.
• Must: ಕೀಗಳನ್ನು ಎಂದಿಗೂ ಚಾಟ್, ಸಾರ್ವಜನಿಕ ರೆಪೊಸಿಟರಿ ಅಥವಾ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗೆ ಅಂಟಿಸಲಾಗಿಲ್ಲ. ಅಂಟಿಸಿದ್ದರೆ, ಪೂರೈಕೆದಾರರಲ್ಲಿ ಅದನ್ನು ಬದಲಿಸಿ (ಹೊಸದನ್ನು ರಚಿಸಿ, ಹಳೆಯದನ್ನು ಅಳಿಸಿ).
• Should: ಪೂರೈಕೆದಾರರು ನೀಡಿದಲ್ಲಿ ನಿರ್ಬಂಧಿತ ಅಥವಾ ವ್ಯಾಪ್ತಿ-ನಿಗದಿತ ಕೀಗಳನ್ನು ಬಳಸಿ. ಉದಾಹರಣೆಗೆ, Stripe ನಿಮ್ಮ ಇಂಟಿಗ್ರೇಷನ್‌ಗೆ ಬೇಕಾದ ಅನುಮತಿಗಳನ್ನು ಮಾತ್ರ ಹೊಂದಿರುವ ನಿರ್ಬಂಧಿತ ಕೀಗಳನ್ನು ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ.
• Should: ಪರೀಕ್ಷಾ ಮತ್ತು ಲೈವ್ ಕೀಗಳು ಬೇರೆಯಾಗಿವೆ, ಮತ್ತು ನೀವು ಸಿದ್ಧರಾದಾಗ ಮಾತ್ರ ಲೈವ್ ಆ್ಯಪ್ ಲೈವ್ ಕೀಗಳನ್ನು ಬಳಸುತ್ತದೆ.

ಕೆಲವು ಕೀಗಳನ್ನು ಸಾರ್ವಜನಿಕವಾಗಿರಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ — Stripe ನ ಪ್ರಕಾಶಿಸಬಹುದಾದ ಕೀ (pk_…) ಅಥವಾ ನಿಮ್ಮ ಡೊಮೇನ್‌ಗೆ ನಿರ್ಬಂಧಿಸಿದ ನಕ್ಷೆ ಕೀ. ನಿಯಮ ಅಧಿಕಾರ ನೀಡುವ ಕೀಗಳ ಬಗ್ಗೆ, ಕೀ ಹಾಗೆ ಕಾಣುವ ಪ್ರತಿ ಸ್ಟ್ರಿಂಗ್ ಬಗ್ಗೆ ಅಲ್ಲ.

5. ಇನ್‌ಪುಟ್ ಮೌಲ್ಯೀಕರಣ

ಬಳಕೆದಾರ ಕಳುಹಿಸುವ ಯಾವುದೇ ವಿಷಯ — ಫಾರ್ಮ್ ಕ್ಷೇತ್ರಗಳು, ಫೈಲ್ ಅಪ್‌ಲೋಡ್‌ಗಳು, URL ಪ್ಯಾರಾಮೀಟರ್‌ಗಳು — ನಿಮ್ಮ ಫಾರ್ಮ್ ಅನುಮತಿಸುವುದಕ್ಕೆ ಮಾತ್ರವಲ್ಲ, ಯಾವುದೂ ಆಗಿರಬಹುದು.

• Must: ಮೌಲ್ಯೀಕರಣ ಸರ್ವರ್‌ನಲ್ಲಿ ನಡೆಯುತ್ತದೆ, ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಮಾತ್ರವಲ್ಲ. ಬ್ರೌಸರ್ ಪರಿಶೀಲನೆಗಳು ಅನುಕೂಲಕ್ಕಾಗಿ; ಯಾರಾದರೂ ಅವುಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಬಹುದು.
• Must: ಡೇಟಾಬೇಸ್ ಪ್ರಶ್ನೆಗಳು ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ, ಬಳಕೆದಾರ ಇನ್‌ಪುಟ್‌ನಿಂದ ಅಂಟಿಸಿದ ಪಠ್ಯವಲ್ಲ (ಇದು SQL ಇಂಜೆಕ್ಷನ್ ತಡೆಯುತ್ತದೆ). AI ಅನ್ನು ದೃಢೀಕರಿಸಲು ಕೇಳಿ.
• Must: ಬಳಕೆದಾರರು ನಮೂದಿಸುವ ಪಠ್ಯ HTML ಆಗಿ ಚಲಿಸದೆ ಪಠ್ಯವಾಗಿ ತೋರಿಸಲ್ಪಡುತ್ತದೆ. ಪರೀಕ್ಷೆ: ನಿಮ್ಮ ಹೆಸರಾಗಿ <b>hello</b> ನಮೂದಿಸಿ. ನೀವು ದಪ್ಪ ಪಠ್ಯವಲ್ಲ, ಟ್ಯಾಗ್‌ಗಳನ್ನು ನೋಡಬೇಕು.
• Should: ಫೈಲ್ ಅಪ್‌ಲೋಡ್‌ಗಳು ಪ್ರಕಾರ ಮತ್ತು ಗಾತ್ರವನ್ನು ಪರಿಶೀಲಿಸುತ್ತವೆ, ಮತ್ತು ಅಪ್‌ಲೋಡ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳನ್ನು ನಿಮ್ಮ ಆ್ಯಪ್‌ನ ಮುಖ್ಯ ಡೊಮೇನ್‌ನಿಂದ ಚಲಾಯಿಸಬಹುದಾದ ಪುಟಗಳಾಗಿ ನೀಡಲಾಗುವುದಿಲ್ಲ.
• Should: ಬಳಕೆದಾರರಿಗೆ ತೋರಿಸುವ ದೋಷಗಳು ಸರಳವಾಗಿವೆ ("ಏನೋ ತಪ್ಪಾಗಿದೆ"); ವಿವರವಾದ ದೋಷಗಳು ಸರ್ವರ್ ಲಾಗ್‌ಗಳಿಗೆ ಮಾತ್ರ ಹೋಗುತ್ತವೆ.
• 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 ನಲ್ಲಿ ಭದ್ರತಾ-ಸ್ಕ್ಯಾನ್ ಪ್ಯಾನೆಲ್ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಮೇಲಿನ ಪಟ್ಟಿಯೇ ಅನುಸರಿಸಬೇಕಾದ ಪ್ರಕ್ರಿಯೆ. ಸಹಾಯಕವಾದ ಕೆಲವು ವಿಷಯಗಳು:

• ಪ್ರಾಜೆಕ್ಟ್ ರಹಸ್ಯಗಳು. ಕೀಗಳನ್ನು ಪ್ರಾಜೆಕ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು → ರಹಸ್ಯಗಳು ಅಡಿಯಲ್ಲಿ, ಅಥವಾ ಏಜೆಂಟ್ ಚಾಟ್‌ನಲ್ಲಿ ತೋರಿಸುವ ರಹಸ್ಯಗಳ ಕಾರ್ಡ್ ಮೂಲಕ ಸಂಗ್ರಹಿಸಿ, ಇದರಿಂದ ಅವು ನಿಮ್ಮ ಕೋಡ್ ಮತ್ತು ಸಂದೇಶಗಳ ಹೊರಗಿರುತ್ತವೆ. ಲೈವ್ ಆ್ಯಪ್‌ಗೆ ರಹಸ್ಯವನ್ನು ಬದಲಿಸಿದ ನಂತರ, ಮತ್ತೆ ಪ್ರಕಟಿಸಿ.
• ಯೋಜನೆ ಮತ್ತು ಕೇಳಿ ಮೋಡ್‌ಗಳು. ಎಡಿಟ್ ಮಾಡದೆ ಅನುಮತಿಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಏಜೆಂಟ್ ಅನ್ನು ಕೇಳಿ: "Ask ಮೋಡ್‌ನಲ್ಲಿ, ಪ್ರತಿ API ಮಾರ್ಗ ಮತ್ತು ಅದು ಮಾಡುವ ಅನುಮತಿ ಪರಿಶೀಲನೆಯನ್ನು ಪಟ್ಟಿ ಮಾಡಿ."
• /test ಏಜೆಂಟ್ ನಿಮ್ಮ ಪೂರ್ವವೀಕ್ಷಣೆಯಲ್ಲಿ ಬಳಕೆದಾರರಂತೆ ಕ್ಲಿಕ್ ಮಾಡುವಂತೆ ಮಾಡುತ್ತದೆ — ವಿಭಾಗ 2 ರ ಎರಡು-ಖಾತೆ ಪರೀಕ್ಷೆಗೆ ಉಪಯುಕ್ತ.
• ಚೆಕ್‌ಪಾಯಿಂಟ್‌ಗಳು ಏನನ್ನಾದರೂ ಮುರಿದ ಬದಲಾವಣೆಯನ್ನು ಹಿಂತಿರುಗಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತವೆ.

ನೀವು ನಿರ್ಮಿಸುವ ಆ್ಯಪ್‌ಗಳಿಗೆ ಭದ್ರತೆ ಮತ್ತು ದಸ್ತಾವೇಜಿನಲ್ಲಿ ಪರಿಸರ ವೇರಿಯೇಬಲ್‌ಗಳು ಮತ್ತು ರಹಸ್ಯಗಳು ನೋಡಿ. ಮುಂದೆ ಬಳಕೆದಾರ ಖಾತೆಗಳನ್ನು ಸೇರಿಸುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಲಾಗ್-ಇನ್ ಹೇಗೆ ಸೇರಿಸುವುದು ಓದಿ.

ಪ್ರಶ್ನೆಗಳು