3

I am currently working on a prototype project that has a frontend built with Apache Wicket and uses a web.xml file. Since we are prototyping, we don't have any requirements or need to implement any security related features yet. That being said, the project as a whole uses SonarQube for enforcing coding standards, one of which is "Add security-constraint elements to this descriptor" in my web.xml file.

I thought I could simply add in an empty tag e.g. <security-constraint></security-constraint> to the file, which satisfies the sonar rule, but a team member said I shouldn't do this because an empty tag is not the same as no tag at all, and that it can bring in a bunch of default constraints that may break things. I've googled this but I've only been able to find information relating to the sub tags of security-constraint i.e. <web-resource-collection>, <auth-constraint> etc., which say they can bring in default values if left empty.

I have actually added the empty <security-constraint></security-constraint> to my xml file to test this and seen no side effects from doing so, but I'm wondering if this is actually true or have I brought in a bunch of default security constraints without knowing it.

I'm also aware I shouldn't just add things to the project to please Sonar, but as I mentioned in a comment below, the reality of the situation is upper management use Sonar as a way to view project statuses. If it's failing they don't really care why, they just want it to go green.

Eoin
  • 330
  • 1
  • 3
  • 15
  • 1
    You shouldn't add stuff to a project to please `SonarQube` (or any other tools for that matter); just try to find a way to silence that rule for the time being until it becomes relevant. On the other hand, if this is a new project, why would you need a Web Application Deployment Descriptor? I'm assuming you are using (or can use) a modern/compliant Servlet `3.x` container, so all the properties you can mention in `web.xml` can now be provided using the `@WebServlet` annotation..if needed. – x80486 Nov 14 '19 at 16:37
  • I 100% agree with you that we shouldn't be adding things to please SonarQube. That being said, the reality is that I will still get asked by upper management why our project isn't passing the rule checks since that is what they use as part of their metrics, and we have requirements to have all Sonar projects pass. I'm not sure what you mean by being able to use @WebServlet over web.xml, could you evaluate on that if possible? We are currently deploying our app on Wildfly15, – Eoin Nov 14 '19 at 16:44
  • Tell the "upper management" that there are some false positives, that's all. If you are using WildFly `15` then you do not need a `web.xml` file...for sure. I don't know what your file looks like, but if you have nothing relevant in there, just delete it, the application will work as before. – x80486 Nov 14 '19 at 16:57
  • I'm pretty sure I need the `web.xml` file? If I delete it and try to compile the war file it fails with the error `Error assembling WAR: webxml attribute is required` – Eoin Nov 14 '19 at 17:04

1 Answers1

0

I'd suggest you to contact the administrator of your SonarQube instance and tell him/her that this rule does not apply to your project.

If you use Spring Security or Apache Shiro, or something else then you will still have security layer but nothing in web.xml.

martin-g
  • 17,243
  • 2
  • 23
  • 35
  • I have done this, but I have to yet to hear back on whether they will exclude it or not. We don't use Spring Security or Apache Shiro. But do you know if my co-worker is correct? Does an empty tag bring in defaults or is he incorrect? – Eoin Nov 18 '19 at 09:30