16 May How we Diagnosed Serious Issues and Possibly Saved Our Client from Security Breaches
In this case study, we want to take you through a potential security breach situation our client faced a couple of years back. We will highlight a number of serious mistakes we encountered when starting the project, as well as how we came to solve them.
An overview:
| Project duration: | 5 Months |
| Industry: | Service |
| Technology: | NodeJS, REST, PostgreSQL |
| Project goal: | Fix a middle-layer application that should integrate our client’s application with an accounting application. |
| Challenges: |
|
| Results: | We created a middle-layer application from the ground up to integrate our client’s application with an accounting application, enabling precise and real-time data exchange between the two systems. |
About the Client
The client created an app that connects people in need of a certain service with people who offer it. It is a company with over 70 employees, a company that raised $5 million in a Seed round, and their app processed over 8 million work orders and managed services that cost over $2.4 billion.
After such success, they needed to create a middle-layer application that would integrate our client’s application with an accounting application.
While they already had a team working on it, the deadline was approaching fast and we came on board to help out.
What we discovered
As we were included later in the project, we wanted to take a good look at what has been done. What we discovered was a wide range of serious security vulnerabilities and technical debt.
Security vulnerabilities
SQL Injections
This is a common vulnerability where a hacker can send malicious SQL inquiries, tricking the database to give out more information than it should have.
Solution
To mitigate the risk of an attacker tricking the database, we sanitized user inputs and utilized built-in features provided by PostgreSQL clients, such as positional arguments–which help prevent SQL injections by separating SQL queries from user data.
Database Connectivity
In the setup we encountered, the database connectivity was established through a single PostgreSQL account, granting an attacker full data access, not just the middle-layer server’s data.
This poses a significant security risk and can be a costly mistake.
Solution
To enhance the security of the database, we created separate accounts for different users or tasks, each with only the minimum level of access needed to perform their specific tasks.
CORS (Cross-Origin Resource Sharing)
CORS is a security feature implemented in web browsers to control which domains are allowed to make requests to a server.
Allowing requests from any domain can expose the server to potential security threats and data breaches.
Solution
To enhance security, we limited the allowed domains to only those that are trusted and specified what types of requests (HTTP methods) are permitted.
PEM keys, certificates, and hardcoded passwords in repo
Storing sensitive information like private keys, security certificates, and fixed passwords directly in a code repository can be dangerous. If someone gains access to the repository, they could use this information to break into various systems, leading to potential data breaches or other harmful actions.
It’s also challenging to manage and update this sensitive data when it’s stored in the repository, and there’s a risk of accidentally exposing it to unauthorized people.
Solution
We stored sensitive data securely outside the code repository, and limited access to only those who need it.
Meet the team who did it – Book a Call.
Technical Debt
Technical debt refers to the long-term costs incurred by cutting corners or using suboptimal solutions in software development, which may save time initially but create additional work in the future.
In this project code formatting was not used at all, and we also found too much duplicated, non-functional, and unused code.
Time Constraint
In addition to technical debt, time constraints can be a significant challenge in software development projects. Moving the deadline and delivering a project too late can be very costly.
Our team has extensive experience in managing tight deadlines and handling various challenges that may arise along the way.
“What might take 10 days for some, could take 5 with us.”
The Result? Rewriting the Project
After we performed a thorough analysis and identified several dangerous errors, we realized it will be faster to start the project anew. Why? Because we wanted to improve the application security, reduce long-term maintenance, and improve overall code quality.
While initially brought in as a support team, we ended up completely rewriting the project.
These mistakes, while common, are serious and must be avoided since they can be very costly and very dangerous. These issues can arise from negligence, or pure inexperience, and could end up costing you more than taking on a small team of professionals who wouldn’t make these mistakes in the first place.
Our team took on high-level responsibilities and cooperated with the team that was brought on first. The project, even though slightly delayed due to starting again, was a success.
BDIT has experience working with US-based companies, and we are quick to adjust and fuse with your team. Using some of our engineers will result not only in smooth communication and project success, but also in overall lower costs.
Want to learn more about how we do it?
If you’re reading this case study and thinking: “I could really use something like this!” – you might be in need of an outstaffed developers that will improve your security and help you deliver your project on time.