Website Development Security Declaration

0. enough of the cones:
0.1. bicycles - no! We use well-known libraries/frameworks, where a lot has already been fixed
0.2. timely upgrade
0.3. logs and monitoring of suspicious activity.
1. input data for each layer:
1.1. controller layer (code): filtering data from superglobals (all)
1.1.1. data initialization, garbage can be harmful (for example, the same autoglobals)
1.2. model\data layer (sql): use prepared statements or other placeholders, at least escaping
1.3. view layer (html): use escaping wherever data output is required
1.4. layers should not trust each other and trust that no harmful data will arrive.
1.5. minimizing functionality: do what is needed and no more (for example, to upload a file you do NOT need to execute it).
2. data filtering: (xss+code\sql injection)
2.1. to the narrowest possible value. for example, if there should be a number, we try to cast to the number.
2.2. up to a wider range can be run through regular sequences. don't forget about the length.
2.3. if the data is countable (selection from a list), then associate a numerical identifier with the real data.
2.4. Do not overdo it, do not spoil the data with “universal” cleaning.
3. authenticity:
3.1. Minimum data lifetime:
3.1.1. we use session data, for access we use a hard-to-guess identifier
3.1.2. for confirmations: long DISPOSABLE ID.
3.1.3. login, elevation of rights: ID regeneration, password confirmation (session hijacking)
3.1.4. forms and other stateful requests also have a one-time ID (csrf,request\form spoofing)
3.2. depending on the importance of the data, we set the difficulty of checking the user (two-phase login, password generators, forcing complex passwords)
3.3. access rights (both FS and system)
4. client is evil:
4.1. We do not store anything on the client, even in encrypted form. maximum - session id in cookies
4.2. validation on the client is meaningless, only for user convenience
4.3. We don’t rely on data about the OS\browser\…
4.4. encryption on the client is pointless, but necessary (if something is stolen)
4.5. file names, other passwords and appearances are false.
5. DoS warning:
5.1. the data is too long + the size of the downloaded data (pictures, for example)
5.2. many failed login attempts
5.3. a lot of downloads
5.4. many queries adding data (eg comments)
6. About encryption:
6.1. all passwords (in the database) - in the form of hashes with salt, check for cryptographic strength and collisions.
6.2. for sensitive data - stream encryption via HTTPS\SSL with short expiration
6.3. We do not store data in files, especially in open form.
6.4. statics - separately from dynamics, resp. access rights (either read, execute, or write)
6.4.1. preferably - statics are very separate from dynamics (another server, folder, outside the root) i.e. so as not to intersect
7. Extra:
7.1. nothing superfluous - for example, no .svn, passwords, checklists, tadu and generally not vital for work.
7.2. no info-headers - about the software used, versions, paths, files, names
7.3. no error messages, except for hints to the user what he is doing wrong and what he should do.
7.4. the source must be visible, eliminate the possibility of fakes, example:
7.4.1. comments should look like comments and nothing else
7.4.2. in the title of all input windows - the site name and function must be clearly recognizable.
7.5. It’s better to use pretty urls - both for convenience and for hiding data.
System security is determined by its most vulnerable point!