Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Content-Security-Policy HTTP header

A third party vulnerability scan of our domain found an issue with our public status page due a missing CSP HTTP header.  Are there any plans by Atlassian to add this header?

(I know I can add the header via a META tag, but that would require upgrading my plan.  Seems like I should not have to pay extra for basic XSS protection in 2021.)

2 answers

There is a kind of "scriptless XSS": CSSAR (a technique for reading tag attributes with CSS selectors), SVG keylogger using <svg> and <set> tags, Reading attributes with CSS, SVG and scrollbars in WebKit.

There are at least 7 ways how to inject scripts into web page, and 6 of those do not require any input fields.

May be it's better to provide possibility to publish Content Security Policy than relying on invulnerability web app?

It might be a god idea, so maybe Atlassian will add it.

I think my bigger issue is before getting excited about issues on a vulnerability report, there needs to be some effort to validate the vulnerability exists and can be exploited.  I have seen too much of that over the years. Hopefully someone from Atlassian will jump in and comment on adding CSP.


I think the bigger issue is your argument boils down to: "You only need that header if there is a vulnerability in the app, and don't worry we don't have any."

Security is about defense in depth.  What if tomorrow one of the Atlassian devs commits a code change that makes it vulnerable to XSS?

I can see how my comment would be interpreted as such.  I am not saying it shouldn't be acted upon.  In a recent security assessment I was involved in, the penetration testers said they found a vulnerability.  they went on to say they used  a tool to find the issue, but 50 hours of man effort to exploit it.  and then they admitted the data they got (which was a list of file names) still yielded no data because they couldn't circumvent the other controls.  So - yes -defense in depth.  If Atlassian adds it to the Free plan, great.  If they don't or won't, then...  my point is that I have seen too many vulnerability scans show vulnerabilities where the issue couldn't be exploited for other means. No flame war here, my intention was a cautionary comment only.  I won't be upset if Atlassian adds it to the free plan.  (By the way, I do not work for Atlassian.)

Totally understand it's not an actual vulnerability.  It was a warning in the audit that lowered the score.

Fair enough.  That just wan't clear I the original post. good discussion though.  It will be interesting to see if Atlassian decides to add this header to the free plan, even if they don't add META capabilities.  I agree it would be a good idea.  

Like Myron A. Semack likes this


For XSS to be effective, there has to be some way of injecting the XSS into the code.  The public status page has no fields where the user can enter text which would then be executed by the Javascript on the page.

This article gives a great explanation about XSS in general, along with the various types and how to demonstrate them.

Cross Site Scripting (XSS) Attack Tutorial With Examples, Types & Prevention 

Because there are no input fields to interact with, the XSS risk is significantly reduced.  Just because there is no CSP header doesn't mean the page is vulnerable to XSS; only that there is no header.  If your third-party assessment found specific XSS attack vendors which they exploited, that is a different issue.



What about the subscribe to updates button?  There are input fields for email/SMS/etc.

That's true.  For XSS to work, the back end must not be parsing the input correctly. 


The simplest XSS test is to put 


in the text field.  If you submit the data and you get an alert back, then your site is at least vulnerable to reflected XSS.   However, with the subscribe to button,


Screen Shot 2021-01-06 at 8.01.27 AM.png

returns this:

Screen Shot 2021-01-06 at 8.01.39 AM.png

even if you go through this verification, there is a brief message displayed indicating you have to enter a valid email address.  

Just because the report says there is a vulnerability doesn't mean you have a valid attack vector.  The primary reason for XSS working is because the developer doesn't do input validation.  For example, by looking for a pattern like, I can quickly determine that 


doesn't meet that pattern and reject it.  Which is what Statuspage does.



Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events