As someone who works in IT Service Management, I'd like to clear up a question you've posed about whether a rollback would be an authorized change -
An issue (defacement of the production website) has occurred that requires an immediate change to be resolved. This is classified as an
emergency change request and you should identify and implement the
procedure for this.
To be clear, the bug / error / mistake that altered and defaced the website was an unintended / unauthorized change. You now must rollback that change, following whatever your company's emergency change request process is. any larger (250 employee or more) organization will have a clearly defined and established process for this.
Now - Don't go making changes without communicating to the Product Owners - If you've made a change to a website that's "owned" by someone else, you need to keep them in the loop. If they're upset, this is probably the component that is upsetting them... people get stressed out when they're responsible for changes or issues that were created by someone else. The best thing you can do here is to make sure they're aware of what happened, and keep them aware of what you're doing to resolve the issue, expected timelines, etc.
Also, if the change is one that they can make, you should communicate with the product owner of this website, and ask whether they'd like you to resolve the issue (if you have the ability to, through your burp suite app), or if they'd like to work on making the changes required to resolve the issue. Do this very, very politely, without implying that "it's their job" and you're shaking your hands of the situation; Ideally, they'll get the sense that you're keeping them in the loop and appropriately allowing them to make the decisions about what's going to happen with their product.
I wouldn't freak out about it - these things happen. Just communicate honestly and openly with everyone involved, and as long as you weren't seriously doing anything out of line (like trying to do someone else's job to subvert different people's authority or do something you're not supposed to), most of the time you'll be fine.
Now, as far as whether rolling back that defaced website is an approved change or not.... Within Change Management, most organizations have a concept of an Emergency Change Request.
An emergency change is typically a change / issue that requires an IMMEDIATE fix, and in some organizations, may happen with severely reduced, or even no approval beforehand.
The procedure for an emergency change request will depend heavily on your organization - Some may say "Go ahead and make your change to bring systems back online etc and then document with an emergency change request after the fact", and some may say "get your emergency CR in and notify your immediate department's Director [Or person involved in approving emergency changes, usually director level] so they can approve it immediately; If they're not available, notify the director in the next adjacent apartment to get it approved"
This is a good opportunity to become aware of what your departments emergency change management policy is, and how it may differ from the regular change management procedure.
Because the reality is - Things happen. Systems may go down, databases may be corrupt... If you have an issue that's occurred in production unintentionally, and need it resolved immediately, you likely need to implement your organizations emergency change request procedure, as it requires changes that won't fit into the regularly scheduled change request processes and windows.
Ask your manager, or their manager (if they're out of office), what your organizations emergency change management procedure is, and explain what happened. They'll guide you through what to do next.
MOST IMPORTANTLY: Do not hide anything you've done. Do not ever lie about what happened, don't let fear convince you to change the way
you would handle this situation. It happens, and 99% of the time, as
long as you take reasonable steps to communicate and handle the issue
that's occurred, you shouldn't worry about getting fired unless you
have really incompetent management or unless the change you've made
has had an extremely severe impact on the company.
Be prepared to explain to your manager (which they'll relay to their manager and / or the other department who's application was impacted) why the issue occurred, and what will be done to prevent or reduce the likelyhood of it happening again in the future. There should be a clear action being taken on this; Either a procedure being implemented, knowledge / training being created to prevent people from making this mistake in the future, etc, something to ensure that someone doesn't end up defacing other production websites in the future.
For example - Could this have been done in a test environment instead, without sacrificing the accuracy of the results? Could the button that defaced the website (or the automated script, if it's automated), be disabled? Could an auto-rollback be implemented after it happens and is tested for? These are useful things to identify and to look at to develop a plan for the future to prevent this from occuring again. This is the kind of thing management above you and the other group will be satisfied with hearing after this issue is resolved, to allow them to move back on to other headaches.