Artemis Financial is a fictitious consulting company that develops individualized financial plans for savings, retirement, investments, and insurance for their patrons. Artemis Financial deals with the private information and financial data of its clients and required a security assessment of its REST API that was in development. Protection from external security threats was the primary focus of the assessment.

In this assessment, I found security vulnerabilities in several different forms. This includes insecure API interactions, insufficient input validation, improper error handling, improper encapsulation, bad coding practices, and lack of encryption for data in transit and data at rest. In any website development, most design and implementation flaws should be found before the site goes live to ensure data privacy and integrity. I did well in this assessment because I found so many vulnerabilities. However, software is a continuous part of any software development cycle, so this is only the first step. Potential consequences from ignoring security vulnerabilities can include Artemis Financial losing money, losing clients, damaging its reputation, and breaking laws.

This was my first time using a static application security testing (SAST) tool, so applying the dependency check tool took some getting used to. However, now that I have extensively used a SAST, I am ready to use it (or others like it) in a live production environment.

I started with fully understanding what the API was doing, and how all of its components contributed to its functionality. Once I had this understanding, I focused on searching the code for vulnerabilities. Strategies that I will employ in the future will be having the mindset like the opponent. Namely, I will think about how hackers will try to exploit the API. I will also have security reference material close by, so I can remind myself of common vulnerabilities in the industry.

To ensure the code was functional, I ran the application to see if it produced expected results. To ensure the security of the application, I followed best practices in refactoring, and constantly referred to our vulnerabilities reference that gives a brief overview and reminder of security concerns. I used static and dynamic methods of verifying the security of the refactored code.

The SAST tool we used (“Dependency Check”) that checks application dependencies for vulnerabilities was very useful throughout my assessment. In addition, the CVE and NVD vulnerability report databases are paramount resources for mitigation of known vulnerabilities. Effectively using these tools and repositories is important for any software developer. Reference material such as O’Reilly textbooks that remind me of best practices and common vulnerabilities were extremely helpful when performing this assessment. Lastly, the OWASP and SANS top vulnerabilities lists are great for keeping common security issues in mind.

In this class, I have learned much about developing secure software. This vulnerability assessment exemplifies my knowledge in external security threats, data integrity, data confidentiality, and the seven main security topics that web APIs must be competent in. This project shows that I can manually review a Java codebase and explain the vulnerabilities I found with complex security concepts. It also shows that I can use static application security testing tools to find known vulnerabilities in dependencies. Finally, it shows that I can devise an action plan to mitigate both the local and dependency-related vulnerabilities.