As a back end developer, we have a big job. We make apps that manage people’s data and we can make code that does many things to them whether they’re good or not.
In this article, we’ll look at some security best practices to take note of when we’re developing back end apps.
Suspicious Action Throttling or Blocking
We should have a way to detect suspicious activities and throttle or block them to prevent various kinds of attacks.
We can use content delivery networks like Cloudflare to detect suspicious traffic and block them at their source.
Also, we shouldn’t let people do things that’ll overload our systems by slowing down downloads and doing other things that won’t let them do too many operations at once.
The number of requests that can be made should also be throttled so that clients can’t make too many requests at a time and overwhelm our systems.
If the activities that are overloading our systems are persistent, then blocking the source that commits those actions are required.
For instance, we can’t let users make 100 requests a second to get customer information.
Also, other suspicious activities include deleting or editing lots of data at once.
Use Anonymized Data for Development and Analysis
We should only use as much data as we need for the purpose that we’re using them for.
For instance, if we’re developing our app with production-quality data, then we take data from production and then anonymize them so that we can’t see all of our customers’ private data.
Likewise, we should anonymize data that are used for statistical analysis. This is very important since we don’t want to show everyone’s private data when we’re analyzing them internally.
If we don’t need to see it, then we shouldn’t see it.
Temporary File Storage
We should know where we’re storing a temporary file. If we’re using publically accessible directories that we should make sure that they’re made read-only for users other than the user the app is running it as.
We can also use the protected directory to store temporary files for our app.
Security for Shared Server Environment
We should be aware of the security implications for hosting our apps on a shared server environment.
It’s possible that other people can have access to our app’s files if we host it on a shared environment.
We should check if our app’s logs, temporary files, etc. are accessible to the outside.
Of course, it’s not good that we expose those files to other virtual servers that share the same host machine for example.
Therefore, we should think about all the things that are stored on those virtual servers including:
- source code
- data
- temporary files
- configuration files
- version control directories
- startup scripts
- log files
- crash dumps
- private keys
and more.
They all have valuable information, so we should make sure that they’re secured from the outside.
We should make sure that our file permissions or set up correctly so that only authorized users can do things to the files that we want them to.
Application Monitoring
Monitoring is definitely important from the security perspective.
We have to check that nothing suspicious is showing on our app’s logs.
However, we should control how logs are displayed to different users.
We don’t want all users to have access to all log data, which may have private data in it.
Therefore, we should just have a subset of users that can access the logs in ways that they’re needed.
We may want to restrict log access by users or IP addresses. Those are usually good candidates to restrict access by.
Risks of APIs
APIs can do powerful things if we let them. Therefore, we should carefully restrict any powerful actions to users that have access to those APIs.
We got to have property authentication and authorization mechanisms so that we can make sure that only the people that we allow can access resources that they should access.
Otherwise, we give attackers a chance to do anything with our systems.
Usually, external APIs are secured with an API key or OAuth. They’re both good for securing our APIs.
For internal APIs, we may also secure them with session stores and a JSON web token to check if a user is allowed to do a given action.
Conclusion
We should make sure that we don’t expose too much data to the public.
APIs should be acknowledged for the power that they can bring. We should secure them.
Also, we should detect any suspicious activity and throttle or block them.
