Confluence provides with different ways of extending its functionality, including a powerful API that gives you access to pretty much the whole system.
This documents talks about what measures should be taken as Administrator and Developers when installing and developing extensions. Most of the measures are common-sense/best-know practices but it also gets into a details on development. For a general overview, you can go to the Confluence Security page.
For Administrators
 | I have to say this: Make sure that only one or a very restricted set of users can actually install plugins! |
Yeah, users are going to beg you to install this really, really cool plugin, but you have to keep some things in mind:
- Is the source code available? if not, does it come from a trusted vendor or contributor?
- Do you understand what the plugin does? would it have impact on performance?
- What people is saying about it (in-page comments, forums, JIRA issues)?
- Is it actively maintained?
Ok, so if you are happy with all of the above then:
- Install it on a sandbox/testing server first
- Keep track on what you installed and when. Remember this when/if people start reporting weird behavior
- Watch the plugin's page and subscribe to the users forum, to received notifications when the plugin is updated
For Developers
OK, so what are the risks?
| Given access to restricted content | Confluences does very well on restricting access to content based on its permission model. However when you are using the API, you are going to get whatever you want, so you have to ensure you also check if the current user has the appropriate permission before performing any operation. |
| Cross-site scripting | If your plugin/user-macro renders HTML and you just display values entered by users, somebody could enter a value to inject malicious javascript code. |
| Crashing or damaging the integrity of the system | The API is very powerful, you could even circumvent controls made to ensure transaction and data integrity  An infinite loop or a deadlock could also cause damage. |
Best practices
User Macros
- If your user macro renders HTML and you render any of the macro parameters or body, use $generalUtil.htmlEncode()
Plugins
- If you have to render to HTML directly then you also have to make sure that any input that could be provided by the user (either actual HTML input, URL parameters and macro parameters are properly encoded:
- If possible, restrict the use of funny characters (i.e. <,>,& etc)
- either HTML encode right away when you get the input, or when it is displayed in the velocity template using GeneralUtil.htmlEncode() or $generalUtil.htmlEncode() on .vm files.
- If you are doing something beyond rendering content, then try to do it in a similar way Atlassian is already doing by examining the Source Code first. If in doubt, ask.
- Make sure you check the user has the proper permission when performing operations as describe in How do I tell if a user has permission to...?
- Stick to the Managers pattern used throughout the application and also in most of the Plugins. This way you limit complex functionality to a discrete number of classes.
- Careful with multithreading in managers. Don't just go and make everything synchronized but make sure you understand what's going on and where there is potential for deadlock and race conditions.
Authenticators
Don't have specifics on this one other than
- Be very careful!
- Get your code peer reviewed/audited
- Log any weird behavior
- make sure you cover all the use cases
Remote API
 |
I am not that familiar with the Remote API, so please somebody elaborate on best practices |
Related Content
General Atlassian Plugin Developer Best Practices
TODO
There is a lot of stuff that could be added, but I don't have time, please feel free to contribute!