defensive design

defensive design

1. to keep programs from tampering you need to use defensive design

   • defensive design helps to ensure programs function properly
     • programmers try to protect their programs through defensive design
   • when programs are functioning correctly they should never break and never produce errors

2. the easiest way for a user to accidentally or intentionally misuse a program is when entering data

   • there are two ways that you can prevent users from entering something you don't want them to; input sanitisation or input validation.

3. programs can use a mixture of input sanitastion and validation to verify that the inputted

   • a white list is a list of all data that a program should accept - any data that isn't on the whitelist will be rejected.
     • a blacklist is a list of all the data that a program should reject - any data that isn't on the blacklist will be accepted

4. sanitisation and validation are often done using whitelists and blacklists .

   • white lists tend to be more secure, however they can take a long time to set up and can be too restrictive.
     • authentication can confirm the identity of a user before theyre allowed to access certain pieces of data or features of the program.

5. passwords are usually associated with a username, when someone tries to access a protected part of the program, it should ask for their password to check that they are who they claim to be.

   • as part of the defensive design program, programmers should make sure that it is well maintained
     • a well maintained program makes it easy for other programmers to understand what the code does

6. testing

   • programming errors can be syntax errors and logic errors
     • syntax errors are when the complier or interpreter doesn't understand something you've typed because it doesn't follow the rules or grammer of the programming language
       • logic errors are when the complier or interpreter or complier are able to run the program, but the program does something unexpected

7. syntax errors can be diagnosed by compilers and interpreters - they'll be unable to turn the source code into machine code and a syntax error

   • logic errors are more difficult to diagnose and track down - compliers and interpreters wont pick them up .

8. functionality testing is an essential part of the development process and a good way to spot logic errors .

   • other types of testing will depend on what the program or system will be used for
     • performance test, usability test, security test, load/stress test