diff --git a/.student_resources/security_testing_approaches/README.md b/.student_resources/security_testing_approaches/README.md
index 31bf095..e16f99f 100644
--- a/.student_resources/security_testing_approaches/README.md
+++ b/.student_resources/security_testing_approaches/README.md
@@ -1,6 +1,6 @@
 # Security Testing Approaches
 
-Software Engineers should consider security and privacy at every phase of the SDLC to ensure that security is an integral part of the development process. As an application moves through phases of the SDLC the cost of patching a vilnerability increases.
+Software Engineers should consider security and privacy at every phase of the SDLC to ensure that security is an integral part of the development process. As an application moves through phases of the SDLC, the cost of patching a vulnerability increases.
 
 | Phase | Security by Design Processes |
 | -------- | ------- |
@@ -13,24 +13,24 @@ Software Engineers should consider security and privacy at every phase of the SD
 | Installation | <ul><li>Penetration testing</li><li>Vulnerability assessment</li></ul> |
 
 ## Code review
-Code review is the process of thoroughly examining and evaluating the source code of an application to identify any potential security vulnerabilities at the code level. Code review is a manual approach to whitebox testing.
+Code review is the process of thoroughly examining and evaluating an application's source code to identify potential security vulnerabilities at the code level. It is a manual approach to white-box testing.
 
 | Area of focus | Questions to ask |
 | -------- | ------- |
-| Privacy | <ul><li>Is sensitive data stored that is not required for the purposes of the application?</li><li>Is sensitive data in error logged to the log files?</li><li>Are passwords encryted before storage or use?</li><li>Can users download and delete their data?</li><li>Are users provided access to the privacy policy?</li><li>Are users who shouldn't have access to the log files able to access them (any or all employees)?</li></ul> |
+| Privacy | <ul><li>Is sensitive data stored that is not required for the application?</li><li>Is sensitive data in error logged to the log files?</li><li>Are passwords encryted before storage or use?</li><li>Can users download and delete their data?</li><li>Are users provided access to the privacy policy?</li><li>Are users who shouldn't have access to the log files able to access them (any or all employees)?</li></ul> |
 | Authentication | <ul><li>Are application users authenticated, or are they all treated as anonymous users?</li><li>What factors are used for authentication (such as passwords, tokens, and certificates)?</li><li>If passwords are being used, are there any policies regarding complexity or age in place?</li></ul> |
-| Authorization | <ul><li>Are there different roles that users can be given depending on the applications’ function?</li><li>Is the authorization data cached checked for each incoming request?</li><li>Are there any private, sensitive data files stored in the web root that is not authorized for the regular user?</li></ul> |
+| Authorization | <ul><li>Are there different roles that users can be given depending on the applications’ function?</li><li>Is the authorization data cached checked for each incoming request?</li><li>Are there any private, sensitive data files stored in the web root that are not authorized for the regular user?</li></ul> |
 | Data Validation | <ul><li>Is the user-submitted data validated?</li><li>Is data validated as soon as it comes in from the user or when it is used by the code?</li><li>How is the data validation accomplished (whitelisting, blacklisting, min/max, etc.)?</li><li>Are you using a database? If so, are you passing arguements</li></ul> |
 | Exception/Error Handling | <ul><li>What approach(s) for error handling is being used?</li><li>What kind of details about an error are displayed to the user?</li><li>Are errors logged with enough detail for analysis?</li><li>Are database errors logged with enough detail for analysis?</li></ul> |
 | Session Management | <ul><li>Is there any way the application manages or stores session state, and if so, how?</li><li>How is the session id being generated?</li><li>Is the previous session deleted when a user logs into the site and creates a new session?</li><li>Are tokens used for session management? If yes, what algorithm is used?</li><li>Any timeouts for sessions?</li></ul> |
-| Logging | <ul>Is any type of logging being used within the code?<li>Where are generated log messages sent?</li><li>Are you logging any input that is not validated first or data that has failed validation?</li><li>Are log messages time-stamped?</li><li>  </li><li>Is any sensitive data written to a log (e.g., password, API key, etc.)?</li></ul> |
-| Encryption | <ul>Are there any encryption algorithms used within the code at all?  (SSL, TLS, RSA?)</li><li>Are passwords encrytped before use with a salt and a hash algorythm></li><li>Where did you get the library's implementation, and what version is it using?</li></ul> |
+| Logging | <ul>Is any logging being used within the code?<li>Where are generated log messages sent?</li><li>Are you logging any input that is not validated first or data that has failed validation?</li><li>Are log messages time-stamped?</li><li>  </li><li>Is any sensitive data written to a log (e.g., password, API key, etc.)?</li></ul> |
+| Encryption | <ul>Are there any encryption algorithms used within the code at all?  (SSL, TLS, RSA?)</li><li>Are passwords encrypted before use with a 'salt' and a 'hash' algorithm></li><li>Where did you get the library's implementation, and what version is it using?</li></ul> |
 
 ---
 
 ## Static application security testing (SAST)
 
-Static application security testing (SAST), or static analysis, is a testing methodology that analyzes source code to find security vulnerabilities. SAST usually is an automated approach to to whitebox testing that scans an application before the code is compiled.
+Static application security testing (SAST), or static analysis, is a testing methodology that analyzes source code to find security vulnerabilities. SAST usually is an automated approach to white-box testing that scans an application before the code is compiled.
 
 [List of SAST tools](https://owasp.org/www-community/Source_Code_Analysis_Tools)
 
@@ -45,7 +45,7 @@ Static application security testing (SAST), or static analysis, is a testing met
 ---
 
 ## Dynamic application security testing (DAST)
-Dynamic application security testing (DAST) is a testing methodology in which testers examine an application while it’s running, but have no knowledge of the application’s internal interactions or designs at the system level, and no access or visibility of applications source code. This is an automated approach to “black box”.
+Dynamic application security testing (DAST) is a testing methodology in which testers examine an application while it’s running but have no knowledge of the application’s internal interactions or designs at the system level and no access or visibility of application source code. This is an automated approach to “black-box”.
 
 [List of DAST tools](https://owasp.org/www-community/Vulnerability_Scanning_Tools)
 
@@ -58,27 +58,27 @@ Dynamic application security testing (DAST) is a testing methodology in which te
 
 ## Vulnerability assessment
 
-A vulnerability assessment is a systematic review of security weaknesses in an system. It evaluates if the system is susceptible to any known vulnerabilities, assigns severity levels to those vulnerabilities, and recommends remediation or mitigation. The focus of a vulnerability assessment is infrastructure, processes and practices. It is more about the organisation than the source code of a single application.
+A vulnerability assessment is a systematic review of security weaknesses in a system. It evaluates if the system is susceptible to any known vulnerabilities, assigns severity levels to those vulnerabilities, and recommends remediation or mitigation. The focus of a vulnerability assessment is infrastructure, processes and practices. It is more about the organisation than the source code of a single application.
 
-### Specific vilnerability assessments
+### Specific vulnerability assessments
 
 - *Host assessment* – The assessment of critical servers, which may be vulnerable to attacks.
 - *Network assessment* – The assessment of policies and practices to prevent unauthorized access to private or public networks and network-accessible resources.
 - *Database assessment* – The assessment of databases and data systems for vulnerabilities and misconfigurations, identifying rogue datasets/databases or insecure dev/test environments.
-- *Application scans* – The identifying of security vulnerabilities in web applications and their source code using DAST & SAST approaches.
+- *Application scans* – The identification of security vulnerabilities in web applications and their source code using DAST & SAST approaches.
 
 ## Penetration testing
 
 > [!WARNING]
-> Students MUST be extremely aware of the legal implications of performing un- authorised penetration testing. Students MUST only perform penetration tests on their own applications or a peers with expressed permission.
+> Students MUST be extremely aware of the legal implications of performing unauthorised penetration testing. Students MUST only perform penetration tests on their applications or peers' applications with expressed permission.
 
-Penetration testing (or pen testing) is a security exercise where a cyber-security expert attempts to find and exploit vulnerabilities in a computer system. The purpose of this simulated attack is to identify any weak spots in a system’s defenses which attackers could take advantage of by deploying the same strategies. Penetration testing requires the use of both automated tools and brute force attacks.
+Penetration testing (or pen testing) is a security exercise where a cyber-security expert attempts to find and exploit vulnerabilities in a computer system. The purpose of this simulated attack is to identify any weak spots in a system’s defences that attackers could take advantage of by deploying the same strategies. Penetration testing requires the use of both automated tools and brute-force attacks.
 
 ### Types of penetration testing
 
-- *White-box pen test* - In a white-box pen test, the tester will perform tests with full knowledge of the application often live watching the logs as they perform tests.
+- *White-box pen test* - In a white-box pen test, the tester will perform tests with full knowledge of the application, often live watching the logs as they perform tests.
 - *Grey-box pen test* - In a grey-box pen test, the tester will perform tests with some knowledge on the application.
-- *Black-box pen test* - In a black-box pen test the tester is given no background or insight into the source code and is only provided the front-end of the application.
+- *Black-box pen test* - In a black-box pen test, the tester is given no background or insight into the source code and is only provided the front end of the application.
 - Organisational level penetration testing such as _Covert pen test_, _External pen test_ and _Internal pen test_ are not in the scope of this course.
 
 ### Brute force testing tools/support