Threat#1 Logging should be used to record source, time and summary of sent data to and from users to be used to check if the correct data has been sent to the user. Threat#2 An authentication mechanism should be used for the user to identify the external entity (API) such as two-factor authentication using SMS. Threat#3 Consider the impact and potential mitigations for your custom authentication scheme. SSL certificates could be used to...
Threat#1
Logging should be used to record source, time and summary of sent data to and from users to be used to check if the correct data has been sent to the user.
Threat#2
An authentication mechanism should be used for the user to identify the external entity (API) such as two-factor authentication using SMS.
Threat#3
Consider the impact and potential mitigations for your custom authentication scheme. SSL certificates could be used to authenticate the backend.
Threat#4
Consider if the function called in the backend by the API can work with less access to memory, such as passing data rather than pointers. Copy in data provided, and then validate it. Consider using an interpreted language for the backend such as Java to avoid buffer overflow.
Threat#5
Implement or utilize existing protocol in backend – API communication which is designed to support anti-replay techniques and strong integrity such as TLS.
Threat#6
Ensure you reassemble data before filtering it, and ensure you explicitly handle these sorts of cases.
Threat#7
Be sure to understand and document log file elements which come from untrusted sources.
Threat#8
Consider using a standard authentication mechanism to identify the source data store.
Threat#9
Review authorization settings
