Various grammar and format tweaks (OWASP#757)

* Update 12-Test_for_Content_Security_Policy.md Comma added to line 19. * Update Testing_Checklist.md Unified capitalization style in titles. * Update Testing_for_APIs.md Testing steps were edited for clarity and flow. * Update 1-Testing_for_a_Cat_in_a_Box.md Missing semicolon before steps corrected. * Update 3-Format_for_HTTP_Request_Response.md Spelling typos corrected. * Update README.md Suggested punctuation changes were made. Co-authored-by: kingthorin <kingthorin@users.noreply.github.com>
DharmenderRajput · Jun 28, 2021 · 5017b24 · 5017b24
1 parent 8fb386a
commit 5017b24
Show file tree

Hide file tree

Showing 5 changed files with 14 additions and 14 deletions.
diff --git a/README.md b/README.md
@@ -23,13 +23,13 @@ For the last stable release, [check release 4.2](https://github.com/OWASP/wstg/r
 
 Each scenario has an identifier in the format `WSTG-<category>-<number>`, where: 'category' is a 4 character upper case string that identifies the type of test or weakness, and 'number' is a zero-padded numeric value from 01 to 99. For example:`WSTG-INFO-02` is the second Information Gathering test.
 
-The identifiers may change between versions therefore it is preferable that other documents, reports, or tools use the format: `WSTG-<version>-<category>-<number>`, where: 'version' is the version tag with punctuation removed. For example: `WSTG-v42-INFO-02` would be understood to mean specifically the second Information Gathering test from version 4.2.
+The identifiers may change between versions. Therefore, it is preferable that other documents, reports, or tools use the format: `WSTG-<version>-<category>-<number>`, where: 'version' is the version tag with punctuation removed. For example: `WSTG-v42-INFO-02` would be understood to mean specifically the second Information Gathering test from version 4.2.
 
-If identifiers are used without including the `<version>` element then they should be assumed to refer to the latest Web Security Testing Guide content. Obviously as the guide grows and changes this becomes problematic, which is why writers or developers should include the version element.
+If identifiers are used without including the `<version>` element, they should be assumed to refer to the latest Web Security Testing Guide content. Obviously as the guide grows and changes this becomes problematic, which is why writers or developers should include the version element.
 
 ### Linking
 
-Linking to Web Security Testing Guide scenarios should be done using versioned links not `stable` or `latest` which will definitely change with time. However, it is the project team's intention that versioned links not change. For example: `https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server.html`. Note: the `v42` element refers to version 4.2.
+Linking to Web Security Testing Guide scenarios should be done using versioned links not `stable` or `latest`, which will definitely change with time. However, it is the project team's intention that versioned links not change. For example: `https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server.html`. Note: the `v42` element refers to version 4.2.
 
 ## Contributions, Feature Requests, and Feedback
 

diff --git a/Testing_for_APIs.md b/Testing_for_APIs.md
@@ -60,10 +60,10 @@ Web authentication types are based on:
 
 ### Generic Testing Method
 
-Step 1: List endpoint and make different request method: Login with user and then using a spider tool to list the endpoints of this role.
-To examine the endpoints, need to make different request methods and then observe how the API behaves.
+Step 1: List endpoint and make different request method: Login with user profile and use a spider tool to list the endpoints of this role.
+To examine the endpoints, you will need to make different request methods and observe how the API behaves.
 
-Step 2: Exploit bugs- as know how to list endpoints and examine endpoints with HTTP methods at step 1, we will find some way to exploit bugs as some testing strategies below:
+Step 2: Exploit bugs - As know how to list endpoints and examine endpoints with HTTP methods at step 1, we will find some way to exploit bug. Some testing strategies are below:
 
 - IDOR testing
 - Privilege escalation

diff --git a/checklist/Testing_Checklist.md b/checklist/Testing_Checklist.md
@@ -81,7 +81,7 @@ Note: The `Status` column can be set for values similar to "Pass", "Fail", "N/A"
 | WSTG-INPV-15      | Testing for HTTP Splitting Smuggling                                       |        |       |
 | WSTG-INPV-16      | Testing for HTTP Incoming Requests                                         |        |       |
 | WSTG-INPV-17      | Testing for Host Header Injection                                          |        |       |
-| WSTG-INPV-18      | Testing for Server-side Template Injection                                 |        |       |
+| WSTG-INPV-18      | Testing for Server-Side Template Injection                                 |        |       |
 | WSTG-INPV-19      | Testing for Server-Side Request Forgery                                    |        |       |
 | **WSTG-ERRH**     | **Error Handling**                                                         |        |       |
 | WSTG-ERRH-01      | Testing for Improper Error Handling                                        |        |       |
@@ -96,18 +96,18 @@ Note: The `Status` column can be set for values similar to "Pass", "Fail", "N/A"
 | WSTG-BUSL-02      | Test Ability to Forge Requests                                             |        |       |
 | WSTG-BUSL-03      | Test Integrity Checks                                                      |        |       |
 | WSTG-BUSL-04      | Test for Process Timing                                                    |        |       |
-| WSTG-BUSL-05      | Test Number of Times a Function Can be Used Limits                         |        |       |
+| WSTG-BUSL-05      | Test Number of Times a Function Can Be Used Limits                         |        |       |
 | WSTG-BUSL-06      | Testing for the Circumvention of Work Flows                                |        |       |
 | WSTG-BUSL-07      | Test Defenses Against Application Misuse                                   |        |       |
 | WSTG-BUSL-08      | Test Upload of Unexpected File Types                                       |        |       |
 | WSTG-BUSL-09      | Test Upload of Malicious Files                                             |        |       |
 | **WSTG-CLIENT**   | **Client-side Testing**                                                    |        |       |
-| WSTG-CLNT-01      | Testing for DOM based Cross Site Scripting                                 |        |       |
+| WSTG-CLNT-01      | Testing for DOM Based Cross Site Scripting                                 |        |       |
 | WSTG-CLNT-02      | Testing for JavaScript Execution                                           |        |       |
 | WSTG-CLNT-03      | Testing for HTML Injection                                                 |        |       |
-| WSTG-CLNT-04      | Testing for Client-side URL Redirect                                       |        |       |
+| WSTG-CLNT-04      | Testing for Client-Side URL Redirect                                       |        |       |
 | WSTG-CLNT-05      | Testing for CSS Injection                                                  |        |       |
-| WSTG-CLNT-06      | Testing for Client-side Resource Manipulation                              |        |       |
+| WSTG-CLNT-06      | Testing for Client-Side Resource Manipulation                              |        |       |
 | WSTG-CLNT-07      | Test Cross Origin Resource Sharing                                         |        |       |
 | WSTG-CLNT-08      | Testing for Cross Site Flashing                                            |        |       |
 | WSTG-CLNT-09      | Testing for Clickjacking                                                   |        |       |

diff --git a/...ration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy.md b/...ration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy.md
@@ -16,7 +16,7 @@ Content Security Policy supports directives which allow granular control to the
 
 ## How to Test
 
-To test for misconfigurations in CSPs, look for insecure configurations by examining `Content-Security-Policy` HTTP response header or CSP `meta` element in a proxy tool:
+To test for misconfigurations in CSPs, look for insecure configurations by examining the `Content-Security-Policy` HTTP response header or CSP `meta` element in a proxy tool:
 
 - `unsafe-inline` directive enables inline scripts or styles making the applications susceptible to XSS attacks.
 - `unsafe-eval` directive allows `eval()` to be used in the application.

diff --git a/template/999-Foo_Testing/3-Format_for_HTTP_Request_Response.md b/template/999-Foo_Testing/3-Format_for_HTTP_Request_Response.md
@@ -43,10 +43,10 @@ HTTP/1.1 200
 
 In this result, the response identifies the server as Tomcat 10.0.4.
 
-## Example Explaination
+## Example Explanation
 
 - The HTTP request and response have text describing them to the reader before the request and response.
 - The GET request has the smallest amount of headers to have the desired response from the server.
     - For example, there is no `User-Agent:` as it is not needed for the "test case".
 - The article uses brackets and ellipsis `[...]` to cut out unnecessary parts of the response.
-    - Unnecessary response content for this sample include the `Content-Type:` header and the rest of the HTML in the body.
+    - Unnecessary response content for this sample includes the `Content-Type:` header and the rest of the HTML in the body.