Context Your company has asked you to create a secure web application, specifically from the perspective of secure software development. Before releasing and making your app public, your manager would like you to assess how secure the code is. To do so, you will try the attacks you practised in this module, then use tools, such as OWASP ZAP, to find more vulnerabilities and weaknesses. At each stage, you will need to provide advice on mitigation and demonstrate that it does, indeed, “plug it”. Tasks For this assessment, you are required to develop a web application that: is fronted by a login page validating a combination of username and password takes the user to a personal space where they are invited to type something that is stored in persistent storage contains a link allowing the user to see all past entries. There are three parts to this assessment, which you will submit as a single report (max 3,000 words +/- 10%), with code in the appendix. Part 1: Secure web app design and implementation First, assess and characterise the security of the application as it was written in the first instance (before applying any mitigations). The code must then be secured and shown to be secure using best practices. To complete this part of the assignment report, you are required to: briefly introduce your app, what it sets itself to do, and its overall architecture (diagrams can help) develop the code, test and show it delivers the requirements set before attack your own website using the techniques covered in this module so far (for example, SQL injection, XSS, but others exist, and you should refer to the module materials.) secure your code against the attacks you identified. You will need to decide based on your attack whether you are going to implement more security controls or take other actions to mitigate identified risks. In many cases, simply understanding the security risks, the underlying technologies, and potential mitigations has the same mark as actually putting mitigations in place. Function choice: You can choose the function of your app, for example, it could be an app about jokes, books you own or birthdays. Once you have chosen your app’s theme, you must share your intended approach with your tutor. Part 2: Security testing and tool usage For this second part, you will security-test the application covering both frontend and backend, using appropriate tools. This part of your assignment report will need to contain: details of at least two sets of tools used in testing explanations of techniques used in the software to improve security, namely secure functions/methods (list its prototype), input validation, SAST/DAST/SCA/etc, unit testing, and exception handling. You are encouraged to go “above and beyond” by attaching security mechanisms to your solution so as to increase its resilience. The items listed above should therefore be viewed as a minimum to include in your report. Part 3: Reflection and application of learning In this third and final part of Summative Assessment 1, you are required to reflect on your software development. It is important that your reflections align with what you have learned in this module so far and apply it to your own assessment work and observations. Note: You will not be assessed on your user interface, so keep it simple by focusing on functionality and not how it looks. Submission requirements Your assessment submission should: be a single 3,000 word report (+/- 10%) clearly identify in the parts of this assessment with your report document your original, insecure code, showing the strict functionality contain your secured code include any security measures you recommend that are not implemented explain what tool(s) you used to identify vulnerabilities and weaknesses and their results explain what vulnerabilities and weaknesses you mitigated and how explain how you developed your application from the angle of software development methodologies discuss how your application impacted requirement elicitation and maintenance from a security perspective explain and evidence your rationale and thought process, as these are more important than the actual code show a clear understanding of how web apps work contain appropriate figures and screenshots that are readable without substantial zooming not use figures and screenshots to reduce word count contain sufficient context for all figures and screenshots so they can be clearly attributed to you not contain generic images evidence that your project ran as you claimed, without your tutor needing to open or run your source code reference any reused code taken from module activities be well-structured, clearly written, and logically organised. use appropriate language and academic writing conventions properly cite any sources or references used in your reflection using Harvard referencing style. Your word count includes the following: headings subheadings in-text citations. The following are not included in your word count: cover page contents table list of figures/tables tables* figures* (for example, diagrams, pictures, charts) list of references appendices page header/footer *Whilst tables, charts, figures, pictures and appendices are excluded, they should not be used excessively as a device to avoid the constraints of the word limit. A marker may disregard such content or reduce the marks awarded. Note: Your source code will not be assessed or checked, except when there are doubts about authorship. Only your report will be reviewed, so it must have sufficient evidence of your work (for example, snippets of code and screenshots). If your submission exceeds the designated maximum word count by more than 10%, this will be taken into account during the marking process. There is no additional penalty for assessments that fall below a specified word limit or range. Ethical requirements No primary data collection is required. If you wish to collect or use data that is not publicly available. For example, obtain appropriate written organisational approval before using any internal corporate data from an organisation you have access to. Such permission should be included in an appendix in the References document. Position regarding generative artificial intelligence Aston embraces the constructive application and use of generative AI, where relevant to programme and/or module learning outcomes. However, generative AI can only be used as a tool in your learning journey and not to create, even if partially, your submission. Furthermore, if you use any AI-generated material, you must disclose and clearly signal it in the report. Examples of constructive use of generative AI include: Generating a study plan. Summarising, reformatting, or translating readings and notes. Editing and generating video, but the words and thought process portrayed must be yours Generating feedback on ideas or a work in progress. Identifying spelling, grammar, and punctuation errors for editorial development. It is a student’s responsibility to: Ask if you are uncertain about the requirements. Use AI critically and constructively in learning, but check its outputs, and do not copy text or any other material generated from prompts into assessed work unless specifically required to and/or clearly attributed. Fully acknowledge the use of generative AI when permitted to use its output. For example, acknowledge the source of a generated figure when labelling it.