Python support has arrived in the guided Copilot experience for VS Code
When we introduced the guided Copilot experience for building Azure apps in VS Code, we started with JavaScript and TypeScript, with Python on the roadmap. Since then, we've seen people creating Python projects with the experience, and we wanted to make sure our Python lovers had proper support. Today, we're excited to announce that the guided Copilot experience in VS Code now fully supports Python projects. đ From Python idea to Azure app The guided experience helps you move from an idea to a deployed Azure app through a structured workflow, with checkpoints for reviewing important decisions. Now Python developers can use that same experience to: Plan and scaffold: Describe your app, review the proposed architecture, and approve a plan before code is generated. Develop locally: Get help preparing your development environment, then run and iterate on your Python project in VS Code. Deploy to Azure: Review the deployment tools, resources, and estimated costs before deploying your app. This guided path complements the free-form Copilot workflows you already know, so you can choose the approach that works best for you. Give it a try Install the Azure Tools extension pack, open an empty folder in VS Code, and start the guided Copilot experience with your Python project in mind. Whether you're building an API, prototyping an idea, or learning something new, we'd love to see what you create. Have feedback? Share it with us on GitHub. Thanks to everyone who's been building Python projects with the experience. We're excited to see what you make next!
Bulk task changes
Does anyone know how am I able to add dates to tasks in bulk if it's the same due date? How do I assign tasks in bulk to a specific person? These used to easily be done by selecting the sections and right clicking to change but many settings updated today and I am no longer able to do this.Azure API Management v2: Restoring Predictable Outbound IP Addresses with NAT Gateway
Introduction A key consideration when deploying Azure API Management Standard v2 or Premium v2 is that outbound networking behavior differs from the classic tiers. This applies both when customers manually rebuild an existing solution on one of these tiers and when they create a new deployment based on assumptions formed from classic-tier behavior. In classic tiers, dedicated outbound IP addresses are available and are commonly used by backend services for source-IP allowlisting. With Standard v2 and Premium v2, customers should instead design outbound connectivity explicitly when a predictable public source IP is required. This article applies only to Standard v2 with virtual network integration and Premium v2 with either virtual network integration or virtual network injection. The Challenge Many backend systems still validate the source IP address of incoming traffic. Common examples include: Partner APIs Payment providers Legacy applications On-premises systems Third-party SaaS platforms When designing a new APIM v2 service, or manually rebuilding a solution previously hosted on a classic tier, backend teams often ask: âWhich IP address should we allowlist?â Unlike a classic-tier design that relies on the serviceâs dedicated outbound IP addresses, an APIM v2 service may require an explicit egress pattern. Virtual network integration combined with Azure NAT Gateway can provide a predictable public source IP for outbound traffic that traverses the integrated subnet. Architecture Before: Classic APIM The backend allowlist contains the outbound public IP address associated with the APIM instance. After: APIM v2 Service with NAT Gateway The backend allowlist contains the public IP address assigned to the NAT Gateway. APIM outbound traffic uses the virtual network integration path, and the NAT Gateway provides the predictable public source IP for internet-bound connections from the associated subnet. Configuration Steps Prerequisite - Create an APIM v2 Service The portal walkthrough in this article uses a Standard v2 instance configured for outbound virtual network integration. As shown in the service overview, the dedicated public IP address information available in the classic tiers is not displayed for this APIM v2 instance. Step 1 - Create a Virtual Network Create or select the virtual network that will be used for APIM outbound virtual network integration. Step 2 - Create a Dedicated APIM Subnet Create a subnet dedicated to the APIM v2 instance. The integration subnet must meet the documented requirements for outbound virtual network integration. Reference: Integrate an API Management instance with a virtual network for outbound connectivity Subnet delegation depends on the APIM v2 tier: Standard v2: Delegate the subnet to Microsoft.Web/serverFarms for outbound virtual network integration. Premium v2: Delegate the subnet to Microsoft.ApiManagement/service, whether using virtual network integration or virtual network injection. Step 3 - Associate a Network Security Group Associate a Network Security Group (NSG) with the APIM integration subnet. Configure the required rules according to the documented APIM networking dependencies, while also applying the outbound controls required by your environment. Reference: APIM outbound virtual network integration requirements Step 4 - Configure APIM Virtual Network Integration In the Azure portal, open the API Management instance and navigate to Networking > Virtual network integration. Select the virtual network and dedicated subnet, and then save the configuration. Virtual network integration can also be configured when creating the APIM instance. References: Outbound virtual network integration | API Management v2 service tiers overview Test the Current Outbound IP This example uses a second APIM instance as the backend, although any backend service that records the request source IP can be used. Before NAT Gateway is configured, the backend can observe different Azure source IP addresses. The Azure IP Ranges and Service Tags - Public Cloud file is available from the Microsoft Download Center: Download Azure IP Ranges and Service Tags â Public Cloud from Official Microsoft Download Center Step 5 - Create a NAT Gateway Create an Azure NAT Gateway and associate it with one or more Standard public IP addresses or a public IP prefix. The assigned public IP becomes the predictable source address used for applicable outbound connections through the integrated subnet. For this example, the NAT Gateway uses a Standard public IP address resource. Step 6 - Associate the NAT Gateway with the APIM Subnet Open the NAT Gateway configuration and associate it with the APIM integration subnet. After the association is applied, validate that the effective network configuration matches the intended routing, NSG, and outbound connectivity design. Step 7 - Validate Send a test request through APIM to an endpoint that returns the callerâs public IP address, or inspect the destination backend logs. Confirm that the observed source IP matches the public IP assigned to the NAT Gateway. As expected, the source IP address observed by the backend now matches the NAT Gateway public IP address. When to Use This Pattern This pattern is useful when: Backend teams require source-IP allowlisting. Third-party vendors support only IP-based network controls. Legacy integrations cannot be changed quickly. A manual rebuild of a solution previously hosted on an APIM classic tier must preserve predictable outbound addressing. Recommendations A predictable source IP can simplify firewall integration, but it should not replace strong service-to-service authentication. Where supported, combine or replace IP-based controls with mechanisms such as: Mutual TLS (mTLS) OAuth 2.0 Client certificates Managed identity Private endpoints and Private Link Treat IP allowlisting as an additional network control rather than the primary authentication mechanism. Also validate capacity, resiliency, routing, DNS, NSG rules, and dependency access for the complete solution before production deployment. Conclusion APIM v2 services use a different outbound networking model from the classic tiers. For new deployments or manually rebuilt solutions, outbound virtual network integration combined with Azure NAT Gateway can provide a predictable public source IP for applicable outbound traffic and simplify integration with backend firewall rules.Retirement of Microsoft HPC Pack
Overview Microsoft HPC Pack is a Windowsâbased highâperformance computing (HPC) scheduler that enables customers to deploy, manage, and operate HPC workloads in onâpremises and hybrid environments. Since its original release, HPC Pack has supported a range of Windowsâcentric HPC scenarios, including job scheduling, workload orchestration, and integration with Windows Serverâbased technologies. Microsoft is announcing the planned retirement of HPC Pack. For customers looking to run HPC workloads going forward, Microsoftâs supported platform for managed HPC and parallel workloads is Azure Batch. Customers may also adopt any other Azure service as appropriate for their workload. These platforms provide modern, cloudânative capabilities for scheduling, scaling, and operating HPC workloads on Azure. Important Dates Retirement announcement: August 27, 2026 End of Support / retirement date: August 27, 2027 After August 27, 2027, HPC Pack will no longer receive feature updates, bug fixes, or standard product support. No new versions or enhancements will be released. Existing HPC Pack deployments will not be forcibly disabled; however, they will be considered unsupported. Microsoft will not extend HPC Pack 2019 support beyond August 27, 2027, or offer paid post-retirement support. Support During the Retirement Period HPC Pack is now entering a one-year retirement period that ends at End of Support on August 27, 2027. Microsoft will provide limited, retirement-only support during this period. The scope of this support is defined below so customers know what to expect. What Microsoft will provide during the retirement period: Security response, including investigation of applicable security vulnerabilities (CVEs) and any security updates deemed necessary by Microsoft Guidance based on existing Microsoft documentation, published best practices, and previously validated HPC Pack configurations Assistance with support incidents involving supported HPC Pack components and documented product functionality What is NOT included during the retirement period: Non-security bug fixes Performance, reliability, scalability, or optimization improvements New features or feature enhancements Customer-specific hotfixes, custom code changes, or design modifications Validation or certification of new operating systems, hardware platforms, drivers, firmware, third-party software, or dependencies Validation of new deployment architectures, configurations, or integration scenarios Changes to existing product behavior or design Creation of new documentation, guidance, or troubleshooting content Troubleshooting that requires new product investigation beyond existing product knowledge, documentation, or previously validated scenarios New customer onboarding, solution design, or pre-sales assistance Migration planning, migration execution, or migration consulting services Support for configurations, integrations, or deployment scenarios that are outside published documentation, established best practices, or previously validated HPC Pack environments After End of Support (August 27, 2027): HPC Pack will receive no further updates, fixes, or technical support, and deployments will be considered unsupported. What Customers Should Do Customers currently using HPC Pack should begin planning migration to a supported alternative as soon as possible. For most scenarios, the following services are recommended: Azure Batch â for managed scheduling and execution of parallel and HPC workloads Or any other Azure service as appropriate for your workload Resources HPC Pack documentation: Microsoft HPC Pack 2019 Public issue tracker: Azure/hpcpack GitHub repository Next Steps Customers who anticipate needing additional planning assistance or migration guidance should engage early with their Microsoft account team or Cloud Solution Architect (CSA) to help ensure a smooth transition and avoid potential disruption.Run on your schedule: App Service plan start/stop now in public preview
Start and stop your apps together Managing an environment with multiple apps shouldn't mean stopping and starting each app individually. App Service plan start/stop brings that control to the plan level, letting you manage the apps and deployment slots it hosts together. Today, we're announcing the public preview for this feature for Premium v4 (Pv4) and Premium memory-optimized v4 (Pmv4) plans. Stop the plan to take its workloads offline, then start it again when you're ready, without issuing separate commands for each app. NOTE: Start and stop operations are asynchronous: the apps on your plan donât all stop or become ready to serve requests immediately. After you stop a plan, app shutdown and cleanup can continue over the next few minutes. When you start it again, allow time for your applications to become ready before sending traffic. This is particularly useful for development, test, and demo environments that share an operating schedule. Because the operation affects the entire plan, make sure every hosted workload can tolerate the interruption. To bring workloads on a stopped plan back online, start the plan rather than an individual app. Get started with Azure CLI You can call the start and stop REST operations using az rest . Sign in to Azure, select the subscription containing your plan, and set its resource group and name: resourceGroup="[RESOURCE-GROUP-NAME]" planName="[APP-SERVICE-PLAN-NAME]" planId=$(az appservice plan show \ --resource-group "$resourceGroup" \ --name "$planName" \ --query id --output tsv) || exit 1 # Stop the plan. All hosted apps and deployment slots will be unavailable. az rest --method post --url "https://management.azure.com${planId}/stopSites?api-version=2026-07-15" When you're ready to run the workloads again, start the plan: az rest --method post --url "https://management.azure.com${planId}/startSites?api-version=2026-07-15" Plan for application startup time before sending traffic back to the environment. A successful API response isn't a substitute for checking that your applications are ready to serve requests. Get started with the Azure portal You can also use the Azure portal to start and stop your plans. On the App Service plan Overview page, select start and stop as you may have done for your individual apps. If you try to start an app when its App Service plan is stopped, you will get an error letting you know to start the App Service plan instead. NOTE: This feature is rolling out in the portal over the next few weeks. If you don't see the option in the portal yet, check back in a couple days and use the Azure CLI in the meantime. Billing considerations Compute billing for an eligible plan pauses when the plan is stopped, even though app shutdown and cleanup can continue over the next few minutes. Compute billing resumes when the plan is started. Charges for other resources and services can continue. Preview limitations and considerations Supported tiers: Premium v4 and Premium memory-optimized v4 only. Other App Service plan tiers aren't supported. Availability: [Insert confirmed preview regions, cloud availability] Plan-wide impact: All apps and deployment slots on the plan are affected. Don't stop a plan that also hosts workloads that must remain available. Restart at the plan level: Attempting to start an individual app will not restart the plan. You must restart the plan to restart the apps. Automatic scaling: Plans with App Service automatic scaling enabled aren't supported. This is distinct from Azure Monitor autoscale. Scaling in progress: Wait for an in-progress asynchronous scale operation to finish before starting or stopping the plan. Start/stop throttling: Plan start and stop operations are subject to a five-minute throttle. Account for this when scheduling operations or testing repeated start/stop cycles. Changes while stopped: Start the plan before scaling it or making other plan updates. Try the preview Try start/stop on a development or test plan whose apps share an operating schedule. Review the apps and deployment slots it hosts, then use the plan-level commands to stop and start those workloads together instead of managing each app individually. For the API details, see Stop Web Apps and Start Web Apps.Announcing Live Migration for Confidential Computing
Today at Build, Microsoft showcased Live Migration for Confidential Computing, a new capability that helps move IntelÂŽ TDX Confidential VMs to updated infrastructure with limited-service interruption while helping protect VM memory and execution context during migration.
Addressing PHP2Shell CVE-2026-109618 and CVE-2026-109619: upgrade guidance and Azure WAF mitigations
Written in collaboration with yuvalperyâ and Gunjan Jainâ Introduction Today, two critical remote code execution (RCE) vulnerabilities were disclosed in PHP. We strongly recommend that customers upgrade to a patched version of PHP as soon as possible. Upgrading is the only way to fully remediate these vulnerabilities. Read more on the PHP official website. Microsoft has been part of the coordinated industry response to these vulnerabilities, working alongside the PHP Foundation, Wiz, security researchers, and other industry partners to help protect customers. Azure Web Application Firewall (WAF) has developed mitigations against known exploitation patterns to provide an additional layer of protection while customers apply the PHP security updates. These protections are intended to complement patching and are not a replacement for it. About the vulnerabilities: CVE-2026-109618 - RCE via OOM corruption CVE-2026-109619- RCE via stale global state Both vulnerabilities can be exploited over the network without privileges or user interaction, with a high potential impact on confidentiality, integrity, and availability. The vulnerabilities relate to PHP handling of memory when a request terminates abnormally, for example due to memory exhaustion or a fatal error. Under certain conditions, improper memory handling could allow an attacker to achieve remote code execution. Fixed versions: 8.5.12, 8.4.27, 8.3.36, 8.2.35. Refer to vendor guidancefor patching of different versions of PHP. Recommended action: upgrade PHP We recommend that customers: Upgrade all PHP deployments to a patched version, including virtual machines, containers, base images, and platform runtimes. We suggest prioritizing internet-facing workloads. Rebuild and redeploy container images that include their own PHP runtime, since updating the host does not update PHP inside an image. Migrate to a supported PHP branch if the branch currently in use no longer receives security fixes. Treat the Azure WAF mitigations below as a temporary, supplementary measure. They address a specific technique and do not remediate the underlying vulnerabilities. Azure WAF protection If you are unable to upgrade PHP to a patched version immediately, apply the following mitigations in the interim - Azure Front Door WAF: Apply the mitigation using custom rules for request-side mitigation and enable the managed rule for response-side mitigation. Application Gateway WAF: Apply the mitigation using custom rules for request-side mitigation and enable the rewrite rule for response-side mitigation. Application Gateway for Container WAF: Apply the mitigation using custom rules for request-side mitigation. See below sections for details. Mitigation using custom rules These custom rules can help reduce exposure to selected request patterns associated with exploitation techniques for these vulnerabilities. Depending on application traffic, the rules may result in false positives and affect legitimate requests. They are intended as temporary mitigations and do not replace the need to upgrade PHP. Learn more: Azure WAF custom rules for PHP2Shell mitigation. Request-side signals alone may not be sufficient to reliably identify certain exploitation attempts. Signals in the server response can provide additional evidence that malicious activity has occurred, enabling more targeted mitigation with higher confidence and lower false positives. For this vulnerability, Azure WAF identifies known malicious patterns in the session and removes the potentially malicious elements from the response before it reaches the client. This provides an additional layer of protection for supported exploitation scenarios, while patching PHP remains necessary to fully address the underlying vulnerability. Azure Front Door WAF: managed rule A managed rule to handle potential attack vector in response is available for Azure Front Door WAF, its details are as follows: Rule group: MS-ThreatIntel-Response-CVEs Rule ID: 99006001 Default state: disabled. Customers need to enable the rule. Supported rulesets: DRS 2.0, 2.1 and 2.2. Unlike other WAF rules, this rule does not block or challenge any traffic. When the rule identifies malicious signals in the session that provides strong evidence of exploitation, it removes the potentially malicious elements from the response while leaving the remainder of the response unchanged. Mitigation for this rule takes effect only when the rule action is set to Block on anamoly. Please note that the response side mitigation does not generate WAF log entries or hit counts. Application Gateway WAF: rewrite rule Customers can apply an interim mitigation now using the HTTP header rewrite capability of Application Gateway, which is available on v2 SKUs. A WAF managed rule for Application Gateway is expected to roll out at a later date. Until then, we recommend the following rewrite rule: 1. Create a rewrite rule in a rewrite set associated with your routing rule(s). 2. Add a condition that evaluates the Set-Cookie response header against the following regular expression: ^PHPSESSID=(?:[a-zA-Z0-9\-]|%2[Cc])*(?:[^a-zA-Z0-9\-;%]|%(?!2[Cc]))+[a-zA-Z0-9\-]*[^;]+; 3. Set the action to delete the matching Set-Cookie response header. Alternatively, the header can be set to a replacement value of your choice. Please note that setting a value overwrites the entire header, including attributes such as Path=/;. Additional considerations: The rule applies only to a Set-Cookie header that matches the pattern. Other Set-Cookie headers in the same response are not affected. We recommend validating the rule on a non-production gateway before broader deployment. For further information, see Rewrite HTTP headers and URL with Azure Application Gateway. Application Gateway for Containers (AGC): A WAF managed rule for Application Gateway for Containers is expected to roll out at a later date. In the interim, customers can apply the custom rules. Application Gateway for Containers does not support regex-based rewrite rules on HTTP response. Restrict request size The proof-of-concept payloads analyzed so far are about 60 MB each. Attackers may be able to craft smaller payloads, so treat size limits as an extra layer of protection, not a mitigation on their own. Whatever rule set version you use, we recommend the following: Azure WAF on Application Gateway and Application Gateway for Containers The proof-of-concept payloads are well above the default maximum request body size of 128 KB on Application Gateway and Application Gateway for Containers. We recommend setting the maximum request body size in your WAF policy to the smallest value your application needs. Learn more. Azure WAF on Azure Front Door To limit request body size, create a custom rule with a size constraint. For request body checks, the size is measured on the decoded body. Set the limit to the smallest value your application needs and make sure request body inspection is enabled in your WAF policy settings. The following example blocks request bodies larger than 40 KB. This rule supports limits of up to 128 KB. { "name": "BlockLargeRequestBody", "priority": 130, "enabledState": "Enabled", "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariable": "RequestBody", "operator": "GreaterThan", "negateCondition": false, "matchValue": [ "40960" ] } ] } Conclusion Following PHP security guidance and upgrading to a patched version is the recommended and complete remediation. Azure WAF mitigations can help reduce exposure during the upgrade period, and we encourage customers to upgrades at the earliest opportunity. Changelog 10/26/2026 9:00 AM PST - Updated with additional guidance around request size restrictions 10/21/2026 7:00 PM PST â Updated with additional guidance around custom rules
Protect against Brotli CVE-2026-111497 with Azure Web Application Firewall (WAF)
Google Brotli versions 1.0.3 through 1.2.0 contain a buffer overflow vulnerability in the Brotli decoder, according to the recently published CVE-2026-111497. A remote, unauthenticated attacker can send a crafted Brotli-compressed stream to corrupt decoder memory, expose sensitive memory contents, cause a denial of service, or potentially run arbitrary code. Any application that decompresses untrusted Brotli data may be affected. This includes Node.js and Python applications that bundle the vulnerable decoder, and services that accept request bodies with the Content-Encoding: br header. We strongly recommend upgrading Brotli to a patched version: 1.0.10, 1.1.1 or 1.2.1 (Brotli releases). If you use Node.js, upgrade to 22.23.4, 24.22.1 or 26.12.1 (Node.js security release). If you can't patch your applications right away, Azure WAF on Application Gateway, Application Gateway for Containers and Azure Front Door can help mitigate the inbound attack vector, which is Brotli-compressed request bodies sent to your application. Note: Azure WAF inspects only inbound requests to your application. It can't protect applications that fetch and decompress Brotli-encoded responses from external servers. Those applications must be patched. Built-in protection enabled by default If you use Azure WAF with DRS 2.2 on Application Gateway or Azure Front Door Premium, you're protected by default against crafted Brotli-compressed request bodies. Rule 920450 (Paranoia Level 1, enabled by default) checks requests against a list of restricted headers, and DRS 2.2 adds Content-Encoding to that list. The rule has a critical anomaly score, so a single match blocks the request when the WAF policy is in Prevention mode. Earlier rule set versions don't restrict the Content-Encoding header. If you're still on DRS 2.1, CRS 3.2 or earlier, we recommend upgrading to DRS 2.2 to get the latest protection. To learn how, see Upgrade CRS or DRS ruleset version. If your application uses Next.js image optimization, apply the BlockNextImageCVE2026111497 custom rule below, even if you're on DRS 2.2. Custom rules to mitigate CVE-2026-111497 The custom rules block two attack vectors: 1. CVE2026111497 blocks any request whose Content-Encoding header includes the br (Brotli) coding, which this attack uses. DRS 2.2 already covers this vector through rule 920450. We recommend this rule for: WAF policies still on DRS 2.1 or earlier, while you plan the upgrade. WAF policies where rule 920450 is disabled or overridden. Azure Front Door Standard, which supports custom rules only. Managed rule sets require Azure Front Door Premium. WAF policies attached to Azure Application Gateway for Containers. 2. BlockNextImageCVE2026111497 blocks any request to the Next.js image optimization endpoint, including under a base path. It URL-decodes and lowercases the request URI first, so encoded or mixed-case variants are also blocked. No managed rule set covers this vector. We recommend this rule for all WAF policies that protect Next.js applications, whatever rule set version they use. These rules may also block legitimate traffic. The first may block clients sending Brotli-compressed request bodies. The second blocks every image served through Next.js image optimization (for example, by the image component), so those images won't load. If you aren't sure whether your application relies on either, set the action to 'Log traffic only' first, and review your WAF logs before switching to 'Deny traffic'. You can remove the Content-Encoding rule once your applications are patched or your policy uses DRS 2.2. Keep the Next.js image optimization rule until your applications are patched. Azure WAF on Application Gateway and Application Gateway for Containers If you are using CRS 3.0 or CRS 3.1, upgrade your ruleset version to a later version first, then apply the custom rule. { "name": "CVE2026111497", "priority": 100, "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "Content-Encoding" } ], "operator": "Regex", "matchValues": [ "(?:^|,)[ \\t]*br[ \\t]*(?:,|$)" ], "transforms": [ "Lowercase" ] } ] } { "name": "BlockNextImageCVE2026111497", "priority": 90, "ruleType": "MatchRule", "action": "Block", "state": "Enabled", "matchConditions": [ { "matchVariables": [{"variableName": "RequestUri"}], "operator": "Regex", "negationConditon": false, "matchValues": ["^(?:https?://[^/?#]+)?/(?:[^?#]*/)?_next/image/?(?:\\?|$)"], "transforms": ["UrlDecode", "Lowercase"] } ] } Azure WAF on Azure Front Door { "name": "CVE2026111497", "priority": 120, "enabledState": "Enabled", "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariable": "RequestHeader", "selector": "Content-Encoding", "operator": "RegEx", "negateCondition": false, "transforms": [ "Lowercase" ], "matchValue": [ "(?:^|,)[ \\t]*br[ \\t]*(?:,|$)" ] } ] } { "name": "BlockNextImageCVE2026111497", "priority": 90, "ruleType": "MatchRule", "action": "Block", "enabledState": "Enabled", "matchConditions": [ { "matchVariable": "RequestUri", "operator": "RegEx", "negateCondition": false, "matchValue": ["^(?:https?://[^/?#]+)?/(?:[^?#]*/)?_next/image/?(?:\\?|$)"], "transforms": ["UrlDecode", "Lowercase"] } ] } Restrict request size The proof-of-concept payloads analyzed so far are about 23 MB each. Attackers may be able to craft smaller payloads, so treat size limits as an extra layer of protection, not a mitigation on their own. Whatever rule set version you use, we recommend the following: Azure WAF on Application Gateway and Application Gateway for Containers The proof-of-concept payloads are well above the default maximum request body size of 128 KB on Application Gateway and Application Gateway for Containers. We recommend setting the maximum request body size in your WAF policy to the smallest value your application needs. Learn more. Azure WAF on Azure Front Door To limit request body size, create a custom rule with a size constraint. For request body checks, the size is measured on the decoded body. Set the limit to the smallest value your application needs and make sure request body inspection is enabled in your WAF policy settings. The following example blocks request bodies larger than 40 KB. This rule supports limits of up to 128 KB. { "name": "BlockLargeRequestBody", "priority": 130, "enabledState": "Enabled", "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariable": "RequestBody", "operator": "GreaterThan", "negateCondition": false, "matchValue": [ "40960" ] } ] } You can find more information about custom rules on Azure WAF for Application Gateway or for Azure Front Door. Changelog 11/2 9:00 AM PST - Updated with additional custom rulesSecurity Review for Microsoft Edge version 156
We have reviewed the new settings in Microsoft Edge version 156 and determined that there are no additional security settings that require enforcement. The Microsoft Edge version 151 security baseline remains our recommended configuration and can be downloaded from the Microsoft Security Compliance Toolkit. Microsoft Edge versions 153 through 156 introduced 8 new Computer and User settings. To make these settings easier to review, we have included a spreadsheet listing each of the new settings. As a reminder, the Microsoft Edge security baseline now aligns with the Extended Stable Channel, which provides major feature updates on an eight-week cadence while continuing to receive security and quality updates between releases. This provides organizations with additional time to evaluate and deploy feature changes while keeping security protections current. As always, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to share your feedback through the Security Baselines Discussion site or this post.
