Վերը նշվածները մի քանի կետեր են, որոնց հարկավոր է լուրջ ուշադրություն դարձնել, եթե չեք դարձրել ուրեմն ինքներդ եք մեղավոր լինելու եթե ձեր կայքի վրա հարձակվեն:

Հիմա անցնենք ավելի լուրջ թեմաների: Կան մի շարք պրոցեսներ, որոնց պետք է հետևի ոչ միայն կայք պատրաստող անձը, այլ նաև ընկերությունը: Դրան են՝

SQL injection – հարձակում տվյալների բազայի վրա

1. Նախ, լավ կլինի, որ սկսեք օգտագործել URL re-writing գաղափարը (սա նաև կարևոր է SEO-ում)
2. Մի կառուցեք դինամիկ SQL հրամաններ առանց, անվտանգ պարամետրերի կոդավորման մեխանիզմ օգտագործելու: Շատ API-ներ (այդ թվում `ADO + ADO.NET) աջակցություն են ձևակերպել պարամետրերի տեսակը, օրինակ` string, integer, date, և կարող է ապահովել, որ նրանք փակվեն/կոդավորվեն հակերների հարձակումից խուսաթելու համար: Միշտ օգտագործեք այս հնարավորությունները:
3. Միշտ իրականացրեք ձեր կայքի/ծրագրի/համակարգի անվտանգության վերանայումը, մինչև այն կգործարկեք, և ստեղծեք անվտանգության վերանայելու պաշտոնական գործընթաց կոդի ցանկացած տեսակի փոփոխությունից կամ թարմացումից հետո: Այս վերջին կետը ՇԱՏ ԿԱՐԵՎՈՐ Է: Շատ հաճախ եմ լսում, որ թիմերը մանրամասն անվտանգությունը վերանայում են, ապա որոշ ժամանակ անց «իրոք աննշան» փոփոխություն կատարում և բաց են թողնում անվտանգության ստուգումը, ասելով որ «հետո կանենք»: Ո՛Չ, անվտանգությանը պետք է միշտ վերանայել:
4. Երբեք տվյալների բազայում չպահեք զգայուն տվյալները պարզ տեքստային տեսքով: Իմ անձնական կարծիքն այն է, որ գաղտնաբառերը միշտ պետք է լինի միակողմանի hashed (ձեզ պետք չի տեսնել ծածկագիրը, քանի, որ Դուք այն կարող եք միշտ փոփոխել, երբ ցանկանաք):
5. Ստեղծեք ավտոմատ ստուգող համակարգ, որ, եթե ինչ-որ մեկը սկսի փորձարկել ձեր կայքը, դուք ստանաք նամակ թե ինչ սխալմներ են տեղի ունեցել համակարգում: Սա կոգնի բացառել «սա փոքր փոփոխություն է» դրվագից առաջացած պրոբլեմները:
6. Սահմանափակեք տվյալների բազայի թույլատվությունների: Մի թողեք ձեր կայքը կարողանա մուտք գործել, կարդալ/գրել կամ ջնջել մի աղուսյակի պարունակություն, որը այն չի օգտագործում իր ֆունկցիոնալում:
7. Մի թողեք կայքի հասցեներում լինեն SQL հրամաններ