Merge pull request #233 from Santandersecurityresearch/develop

Merge dev to master

.github/dependabot.yml

@@ -3,9 +3,20 @@ updates:
 - package-ecosystem: "pip"
   directory: "/"
   schedule:
-      interval: "daily"
+    interval: "daily"
   target-branch: "develop"    
   reviewers:
     - "danielcuthbert"
     - "javixeneize"
     - "pealtrufo"
+    - "emilejq"
+- package-ecosystem: "github-actions"
+  directory: "/"
+  schedule:
+    interval: "weekly"
+  target-branch: "develop"    
+  reviewers:
+    - "danielcuthbert"
+    - "javixeneize"
+    - "pealtrufo"
+    - "emilejq"

.github/workflows/pull_request.yml

@@ -17,10 +17,12 @@ jobs:
            python-version: ${{ matrix.python-version }}
 
       - name: Install PIP Dependencies
-        run: pip install -r requirements_dev.txt
+        run: |
+          pip install -r requirements.txt
+          pip install -r requirements_dev.txt
 
-      - name: Test with Nosetests
-        run: python -m nose --with-xunit --xunit-file=${{ matrix.python-version }}.results.xml
+      - name: Test with pytest
+        run: python -m pytest --junitxml ${{ matrix.python-version }}.results.xml
 
       - name: Upload Test results
         uses: actions/upload-artifact@master
@@ -36,7 +38,7 @@ jobs:
 
       - name: Safety dependency scan
         run: python -m safety check
-        
+
       - name: Checkout origin branch if PR 'to-branch' is master
         if: github.base_ref == 'master'
         uses: actions/checkout@v2

.github/workflows/release.yml

@@ -1,6 +1,6 @@
 name: Dr Header Release Task
 
-on: 
+on:
   push:
     branches: [ master ]
 
@@ -12,19 +12,21 @@ jobs:
         matrix:
           python-version: [3.7]
     steps:
-      - name: Checkout Code 
+      - name: Checkout Code
         uses: actions/checkout@v2
-      
+
       - name: Set up Python
         uses: actions/setup-python@v1
         with:
           python-version: ${{ matrix.python-version }}
 
       - name: Install dependencies
-        run: pip install -r requirements_dev.txt
-
-      - name: Test with Nosetests
-        run: python -m nose --with-xunit --xunit-file=${{ matrix.python-version }}.results.xml
+        run: |
+          pip install -r requirements.txt
+          pip install -r requirements_dev.txt
+
+      - name: Test with pytest
+        run: python -m pytest --junitxml ${{ matrix.python-version }}.results.xml
 
       - name: Flake8 styles
         run: python -m flake8 drheader
@@ -38,12 +40,12 @@ jobs:
       - name: Make Wheel
         run: |
           python3 setup.py sdist bdist_wheel
-          
+
       - name: Dump build info for release
         run: |
            git log --pretty=oneline > changelog
-           python3 setup.py --version > version     
-           
+           python3 setup.py --version > version
+
       - name: Get bumpversion
         run: echo "VERSION"=$(grep -i 'current_version = ' setup.cfg | head -1 | tr -d 'current_version = ') >> $GITHUB_ENV
 
@@ -57,25 +59,25 @@ jobs:
           release_name: Release v${{ env.VERSION }}
           draft: false
           prerelease: false
-        
+
       - name: Upload Wheel
         id: upload_wheel
         uses: actions/upload-release-asset@v1.0.1
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         with:
-          upload_url: ${{ steps.create_release.outputs.upload_url }} 
+          upload_url: ${{ steps.create_release.outputs.upload_url }}
           asset_path: ./dist/drheader-${{ env.VERSION }}-py2.py3-none-any.whl
           asset_name: DrHeader Wheel
           asset_content_type: application/x-python-wheel
-      
+
       - name: Upload Changelog
         id: upload_changelog
         uses: actions/upload-release-asset@v1.0.1
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         with:
-          upload_url: ${{ steps.create_release.outputs.upload_url }} 
+          upload_url: ${{ steps.create_release.outputs.upload_url }}
           asset_path: changelog
           asset_name: DrHeader changelog
           asset_content_type: text/plain

CONTRIBUTING.md

@@ -56,34 +56,34 @@ Ready to contribute? Here's how to set up
 1.  Fork the <span class="title-ref">drheader</span> repo on GitHub.
 
 2.  Clone your fork locally:
-    
+
         $ git clone git@github.com:your_name_here/drheader.git
 
 3.  Install your local copy into a virtualenv. Assuming you have
     virtualenvwrapper installed, this is how you set up your fork for
     local development:
-    
+
         $ mkvirtualenv drheader
         $ cd drheader/
         $ python setup.py develop
 
 4.  Create a branch for local development:
-    
+
         $ git checkout -b name-of-your-bugfix-or-feature
-    
+
     Now you can make your changes locally.
 
 5.  When you're done making changes, check that your changes pass flake8
     and the tests, including testing other Python versions with tox:
-    
+
         $ flake8 drheader tests
-        $ python setup.py test or py.test
+        $ py.test
         $ tox
-    
+
     To get flake8 and tox, just pip install them into your virtualenv.
 
 6.  Commit your changes and push your branch to GitHub:
-    
+
         $ git add .
         $ git commit -m "Your detailed description of your changes."
         $ git push origin name-of-your-bugfix-or-feature
@@ -95,8 +95,8 @@ Ready to contribute? Here's how to set up
 When submitting a pull request, please ensure that:
 
 1.  You submit it to 'develop' branch and there's no conflicts.
-2.  You check all tests are passing and have created new ones if change not covered in current test suite. 
+2.  You check all tests are passing and have created new ones if change not covered in current test suite.
 3.  You update `README.md` if functionality has been added or modified. If you are creating new classes or methods, please use docstring to document the code.
-4.  You update `RULES.md` when extending or modifying the way rules can be used, adding documentation and examples for the new/modified feature. 
+4.  You update `RULES.md` when extending or modifying the way rules can be used, adding documentation and examples for the new/modified feature.
 5.  Code works for Python >= 3.7
 6.  Once PR is submitted, workflow steps are successful (e.g.: Flake8, Bandit, Safety, etc.)

MANIFEST.in

@@ -4,6 +4,7 @@ include LICENSE
 include README.md
 include RULES.md
 include drheader/*.yml
+include drheader/resources/delimiters.json
 
 recursive-include tests *
 recursive-exclude * __pycache__

README.md

@@ -86,7 +86,7 @@ It is also possible to call drHEADer from within an existing project, and this i
 from drheader import Drheader
 
 # create drheader instance
-drheader_instance = Drheader(headers={'X-XSS-Protection': '1; mode=block'}, status_code=200)
+drheader_instance = Drheader(headers={'X-XSS-Protection': '1; mode=block'})
 
 report = drheader_instance.analyze()
 print(report)
@@ -124,6 +124,25 @@ drheader_instance = Drheader(url="http://test.com", verify=False)
 
 Other arguments may be included in the future such as _timeout_, *allow_redirects* or _proxies_.
 
+#### Cross-Origin Isolation
+The default rules in drHEADer support cross-origin isolation via the `Cross-Origin-Embedder-Policy` and
+`Cross-Origin-Opener-Policy` headers. Due to the potential for this to break websites that have not yet properly
+configured their sub-resources for cross-origin isolation, these validations are opt-in at analysis time. If you want to
+enforce these cross-origin isolation validations, you must pass the `cross-origin-isolated` flag.
+
+Using the CLI:
+```shell
+$ drheader scan single https://example.com --cross-origin-isolated
+```
+
+In a project:
+```python
+import drheader
+
+drheader_instance = drheader.Drheader(url='https://example.com')
+drheader_instance.analyze(cross_origin_isolated=True)
+```
+
 ## How Do I Customise drHEADer Rules?
 
 DrHEADer relies on a yaml file that defines the policy it will use when auditing security headers. The file is located at `./drheader/rules.yml`, and you can customise it to fit your particular needs. Please follow this [link](RULES.md) if you want to know more.
@@ -137,7 +156,7 @@ DrHEADer relies on a yaml file that defines the policy it will use when auditing
 We have a lot of ideas for drHEADer, and will push often as a result. Some of the things you'll see shortly are:
 
 * Building on the Python library to make it easier to embed in your own projects.
-* Releasing the API, which is seperate from the core library - the API allows you to hit URLs or endpoints at scale
+* Releasing the API, which is separate from the core library - the API allows you to hit URLs or endpoints at scale
 * Better integration into MiTM proxies.
 
 ## Who Is Behind It?

RELEASING.md

@@ -1,18 +1,18 @@
 # Releasing
 
-Our approach to releasing new versions is quite simple. A new version will be released everytime there's a push to master branch. 
+Our approach to releasing new versions is quite simple. A new version will be released everytime there's a push to master branch.
 
-We've managed to have all the process to bump version for next release in the different files fully automated by using [github actions](https://github.com/features/actions). 
+We've managed to have all the process to bump version for next release in the different files fully automated by using [GitHub Actions](https://github.com/features/actions).
 
-We currently have 2 github actions configured in this repo, which will be triggered when:
+We currently have 2 GitHub Actions configured in this repo, which will be triggered when:
 
 * There's a pull request.
-    * If the PR is to a non master branch, this action will run standard checks like nosetests, flake8, bandit and safety to ensure everything is good with the code.
+    * If the PR is to a non-master branch, this action will run standard checks like pytest, flake8, bandit and safety to ensure everything is good with the code.
     * If the PR is to the master branch, this action will run standard checks, automatically bump release version number in appropriate files and commit those changes to the pull request branch.
 * There are changes pushed to master branch.
     * This action will run standard checks, create the wheel, the release/tag using the version previously bumped and publish the artefact to Pypi
 
-To bump version in files prior to release, we use [bump2version](https://github.com/c4urself/bump2version). The configuration for it to know what is the current version, what files need to have the version bumped up and what is the next version is in `setup.cfg`. 
+To bump version in files prior to release, we use [bump2version](https://github.com/c4urself/bump2version). The configuration for it to know what is the current version, what files need to have the version bumped up and what is the next version is in `setup.cfg`.
 
 ```ini
 [bumpversion]
@@ -36,6 +36,6 @@ replace = __version__ = '{new_version}'
 ...
 ```
 
-With this configuration, we are specifying that only those three files need to have the version bumped before release. By default, `bump2version` bumps a minor version (ie . from 1.2.2 to 1.3.0), but if we want it to be a major version or a patch bump, we only need to specify the `new_version` attribute in the configuration with the version we want to use for the release. 
+With this configuration, we are specifying that only those three files need to have the version bumped before release. By default, `bump2version` bumps a minor version (ie . from 1.2.2 to 1.3.0), but if we want it to be a major version or a patch bump, we only need to specify the `new_version` attribute in the configuration with the version we want to use for the release.
 
-**Note**: Master and develop branches are protected. It means that we require commits to be pushed through pull requests, status checks to pass before merging and restrict who can push to those branches. We aimed to have the release process fully automated, but because issues described [here](https://gh.neting.ccmunity/t5/GitHub-Actions/How-to-push-to-protected-branches-in-a-GitHub-Action/td-p/29609) or [here](https://gh.neting.ccmunity/t5/GitHub-Actions/Automatic-version-update-in-protected-branch/m-p/56469#M9895) when using github actions for this, we decided that disabling this protection in **develop** branch just when a PR from develop to master is submitted would be a good approach for us, so that the action that bumps the versions and commits the changes back can complete successfuly. 
+**Note**: Master and develop branches are protected. It means that we require commits to be pushed through pull requests, status checks to pass before merging and restrict who can push to those branches. We aimed to have the release process fully automated, but because issues described [here](https://gh.neting.ccmunity/t5/GitHub-Actions/How-to-push-to-protected-branches-in-a-GitHub-Action/td-p/29609) or [here](https://gh.neting.ccmunity/t5/GitHub-Actions/Automatic-version-update-in-protected-branch/m-p/56469#M9895) when using GitHub Actions for this, we decided that disabling this protection in **develop** branch just when a PR from develop to master is submitted would be a good approach for us, so that the action that bumps the versions and commits the changes back can complete successfully.