Kb items corrections

skf/markdown/knowledge_base/131-knowledge_base--HTTP_headers_added_by_a_frontend--.md

@@ -1,8 +1,7 @@
 ## Description:
 
-Use this kind of HTTP headers such as a bearer token only if you have authenticated the server sending the header to your application.
+There are some kind of headers that uses tokens such as Bearer or JWT which are signed or calculated using a key, by the server that creates it.
 
 ## Solution:
 
-Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are
-authenticated by the application.
+Verify the integrity and authenticity of the HTTP headers added by a trusted proxy or SSO devices by checking the digital signature or by recalculating the hash or integrity method using a private key or passphrase.

skf/markdown/knowledge_base/193-knowledge_base--API_resonses_security_headers--.md

@@ -2,9 +2,13 @@
 
 There are some security headers which should be properly configured in order to protect some API callbacks against Reflective File Download and other type of injections.
 
-Also check that the API response is not dynamic, if so use input validation and encoding in order to prevent XSS and Same origin method execution attacks.
+Also check if the API response is dynamic, if user input is reflected in the response. If so, you must validate and encode the input, in order to prevent XSS and Same origin method execution attacks.
 
 ## Solution:
 
-Verify that all API responses contain X-Content-Type-Options: nosniff and Content-Disposition: attachment; filename="api.json" (or other appropriate filename for the content type).
+Sanitize your API's input (in this case they should just allow alphanumeric); escaping is not sufficient
+
+Verify that all API responses contain X-Content-Type-Options: nosniff, to prevent the browser from interpreting files as something else than declared by the content type (this helps prevent XSS if the page is interpreted as html or js).
+
+Add 'Content-Disposition: attachment; filename="filename.extension"' with extension corresponding the file extension and content-type, on APIs that are not going to be rendered
 

skf/markdown/knowledge_base/261-knowledge_base--Policy_for_processing_sensitive_data--.md

@@ -1,7 +1,17 @@
 ## Description: 
 
+Some data on an application can be consider sensitive due to its importance:
+- Social security number
+- Credit card or banking information
+Or by the context of the information:
+- Passphrase used as a password of an application
+- University restricted or critical data
+
+On applications, data considered sensitive should be kept safe. The way we secure the data could be defined by us, but some information it should be made according to a standard - i.e. all applications that manipulate credit card information should comply with one of the pci standards.
 
 
 ## Solution:
 
+Identify the list of sensitive data that is being processed by the application.
 
+Establish, maintain, and disseminate a security policy for processing and storing sensitive data. If information should be encrypted, separated in another database, etc. If exist, follow the appropriate standard.

skf/markdown/knowledge_base/88-knowledge_base--Disallow_the_use_of_old_passwords--.md

@@ -1,8 +1,9 @@
 ## Description:
 
-This is a mitigation of the risk that a password can leak by any means towards a possible attacker.Changing the password to a new one minimizes the damage.
+This is a mitigation of the risk that a password can leak by any means towards a possible attacker. Because of password reuse, this could happen not only due to a leak in your site. Changing the password to a new one minimizes the damage.
+
+Also, users really don't like changing their passwords. So what users used to do when forced to change their password was to change it twice - once to some temporary password and then a second time back to the original password.
 
 ## Solution:
 
-Keep the old entries of the password record of the user. If the user changes his password
-you can match against the old entries to validate it is not an old one.
+Keep a number of password hashes entries greater than the number of times that the change password functionality execution is permitted and validate that the new password hash is not one of those entries.