When an automated tool is creating an issue via HTTP POST request to CreateIssueDetails.jspa and omits request parameter 'security', one would expect that the resulting issue will have Issue Security Scheme's default security level. However, this is currently not the case.

Steps to reproduce:
1. Associate a project with an Issue Security Scheme that have some security levels in it.
2. Assign one of the security levels as the default (i.e., it mustn't be 'None').
3. Make sure the project's Field Configuration Scheme has Security Level field not hidden in the field configuration associated for the issue type you are about to create (e.g. Bug) and also shown on the screen (e.g. Bug create screen).
4. Go to Issues -> Create Issue page, choose this project and issue type (e.g. Bug), press Next.
5. Make sure your configured default security level is displayed in the Security Level select-box as the default (so you know the configuration is correct).
6. Remove HTML element <select name="security".../> using Firebug, Chrome's dev tools or similar (OR use HTTP proxy such as Charles to modify the request)
7. Press Create
8. The resulting issue has Security Level 'None' instead of scheme's default.

I'm not sure whether this behavior is the same when creating issues through RPC APIs, but if it is, it might pose a security risk. I've noticed a method createIssueWithSecurityLevel(token, rIssue, securityLevelId) in Jira SOAP API, but I didn't notice a possibility to query project's (or its associated issue security scheme's) default security level, so it's of little use unless the remote caller knows the default level itself.

The code below could be used to set the default security level in CreateIssueDetails.java:

Object securityParameter = ActionContext.getParameters().get( "security" );    	
if( securityParameter == null )
{
	log.debug( "Request parameter 'security' is missing, trying to set the default security level of issue security scheme" );
	List< GenericValue > issueSecuritySchemes = ComponentManager.getComponentInstanceOfType( 
			IssueSecuritySchemeManager.class ).getSchemes( getProject() );
	if( issueSecuritySchemes != null && !issueSecuritySchemes.isEmpty() )
	{
	    // there are issue security schemes associated with this specific project, continue
	    for( GenericValue securityScheme : issueSecuritySchemes ) // actually there should only be one scheme..
	    {
		Long defaultLevelId = securityScheme.getLong( "defaultlevel" );
		GenericValue defaultLevel = issueSecurityLevelManager.getIssueSecurityLevel( defaultLevelId );
		if( defaultLevel != null && issue != null )
		{
			issue.setSecurityLevel( defaultLevel );
			log.info( "Set scheme's default security level '" + defaultLevel.getString( "name" )
			    + "' for Issue[summary=" + issue.getSummary() + "]" );
		        return;
		}
	    }
	}
}

Probably there are better places for this check, probably where the issue is initially created and fields populated, e.g. in IssueCreationHelperBeanImpl.validateCreateIssueFields() or SecurityLevelSystemField.getValueFromParams():

    public Object getValueFromParams(Map params)
    {
        if (params.containsKey(getId()) && params.get(getId()) != null)
        {
            Long securityLevelId = Long.valueOf((String) params.get(getId()));
            if (NO_SECURITY_LEVEL_ID.equals(securityLevelId))
            {
                return null;
            }
            else
            {
                return getSecurityLevel(securityLevelId);
            }
        }
        else
        {
            CURRENTLY:
            // No parameter could be found so need to set the default security level
            return null;

            SHOULD BE:
            <CODE TO SET THE DEFAULT SECURITY LEVEL>
        }
    }

Or is there a logical explanation why this kind of behavior is considered normal in Jira?