Coordinated disclosure

Reporting a security problem

If you have found a vulnerability in this site, we want to hear about it and we will not treat you as an intruder for telling us. This page is the policy referenced by /.well-known/security.txt. It sets out where to send a report, what we consider in scope, the protection we offer good-faith research, and how fast you can realistically expect a human to answer.

Last reviewed 22 August 2026 · No bug bounty · Report to security@ourelectedportfolios.com

How to report

Email security@ourelectedportfolios.com. That address is monitored for security reports and is the only contact address this project has published. There is no general enquiries address at all — the contact page sets out what else does and does not have a route — so if what you are sending is not a security issue, expect us to say so plainly rather than forward it somewhere.

We do not publish an encryption key today. If a finding is too sensitive to put in a plaintext email, send a short note saying so — without the details — and we will agree a channel before you send anything.

What to put in the report

The exact URL, endpoint or page, and the HTTP method. For an API finding, the full request and the response you got back.
Steps to reproduce, in an order someone else can follow. A short proof of concept beats a paragraph of description.
What an attacker actually gains. “This header is missing” is a note; “this lets me read X” is a report. If you are not sure, say what you tried and what stopped you.
The rough time window of your testing (with a timezone) and the source IP or user agent you used, so we can separate your traffic from everyone else’s in the logs.
Whether you would like to be credited when the issue is fixed, and under what name or handle.

Please do not attach data belonging to anyone else. If your finding exposed information you were not meant to see, describe it — the shape, the field names, roughly how much — rather than sending us a copy of it.

Scope

Scope is deliberately narrow, because it is bounded by what we can actually fix.

In scope

The web application at ourelectedportfolios.com and its www host, including every page it serves.
Its HTTP API on that host — the versioned /api/v1/* routes and the unversioned infrastructure routes alongside them.
The application’s own authorization and data-access behaviour: anything that returns data the caller should not be able to reach, or accepts a write it should have refused.
Injection, request forgery, redirect abuse, header and content-security-policy bypasses, and anything else with a demonstrated path to impact on this application.

Out of scope

Our hosting, database and infrastructure providers’ own systems. We do not control them and cannot authorise testing against them — take those findings to the provider’s own disclosure programme.
Denial of service, volumetric or resource-exhaustion testing, and load generation of any kind. Please do not.
Social engineering, phishing or pretexting aimed at the people who maintain this project, and anything physical.
Raw scanner or automated-tool output with no demonstrated impact, including missing-header and best-practice findings with no exploit path. The API routes are rate-limited, so a heavy automated run against them mostly collects 429s.
A dependency version flagged as outdated, without a working path to impact on this application.

Safe harbour

If you research in good faith and follow this policy, we will treat your work as authorised. We will not pursue civil action against you, will not report you to law enforcement over it, and will not ask your employer, university or hosting provider to act against you. If a third party brings a claim over research that stayed inside this policy, we will make it known that your testing was authorised.

What good faith means here

Stay inside the scope above, and stop as soon as you have proved the issue. Access only the minimum needed to demonstrate it.
If you reach information that is not yours or not public, stop immediately, do not save or share it, and tell us what happened.
Do not degrade, disrupt or damage the service, and do not destroy or alter data.
Give us a reasonable chance to fix the issue before you talk about it publicly — see the timeline below.
Comply with the law that applies to you. Nothing on this page is a licence to break it.

One limit we cannot wave away: this safe harbour is ours to give and covers only us. It does not bind our providers, and it cannot authorise you to test their infrastructure.

What happens after you send it

This is a small project, not a security team with a rota, so these are honest working targets rather than a contractual service level. If we are going to miss one, we would rather tell you than go quiet.

Within 5 working days: A human acknowledges your report and tells you who is looking at it.
Within 10 working days: We tell you whether we reproduced it, how we have rated it, and whether we intend to fix it. If we disagree that it is a vulnerability, we will say why rather than let it lapse.
Until it is closed: We keep you updated as the fix moves, and tell you when it has shipped. Serious issues are worked on ahead of everything else.
90 days: Our default coordinated-disclosure window. Publish after that if you like — and sooner if we have already fixed it and agreed the timing with you. If we need longer, we will ask and explain why.

If ten working days pass with no reply at all, please resend. Assume the mail went astray rather than that you are being ignored.

There is no bug bounty

We want to be blunt about this before you spend a weekend on it: there is no reward programme, no payment, no swag and no paid triage. This site is free to read, it has no paid tier and no checkout, and there is no budget behind this address.

What we can offer is a real reply from a person and a fix. We can also credit you, under whatever name or handle you give us — but be clear about what that is worth today: this repository is private and there is no public changelog or releases feed to print a name in, so if you want the credit to be public we will agree where it goes rather than point you at a page that does not exist.

How the project handles its own security

The project keeps a written threat model, a hardening backlog and a record of each security pass alongside the source, together with database-level tests that assert the access rules rather than assuming them. Those documents are not public today, and we would rather say that than link you to something you cannot open. If a report of yours turns on how a particular control is meant to behave, ask in the thread and we will quote you the relevant part.

No independent security audit has been carried out on this site. If that changes, this section changes with it.

What this page is not

This is a security policy. It is not privacy or terms copy, and it is not a statement about the filings this site intends to publish. Our Elected Portfolios is not affiliated with, endorsed by or operated by the House of Representatives, the Senate or any other government body, and nothing here or elsewhere on the site is investment advice.